kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2019-11-27 06:06:40 +00:00
parent 91f027ede4
commit 688e33953d
19 changed files with 82 additions and 82 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
View file

@ -367,7 +367,7 @@ If we take a look at the project's main page on the GitLab UI, we can see the st
build made by GitLab CI/CD.
Time to show the world our green build badge! Navigate to your project's **Settings > CI/CD** and
expand **General pipelines settings**. Scroll down to **Pipeline status** and copy the markdown code
expand **General pipelines settings**. Scroll down to **Pipeline status** and copy the Markdown code
for your badge. Paste it on the top of your `README.md` file, to let people outside of our project
see if our latest code is running without errors.

2
doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
View file

@ -96,7 +96,7 @@ To check these feature flag values, please ask administrator to execute the foll
### Intermittently pipelines fail by `fatal: reference is not a tree:` error
Since pipelines for merged results are a run on a merge ref of a merge request
(`refs/merge-requests/<iid>/merge`), the git-reference could be overwritten at an
(`refs/merge-requests/<iid>/merge`), the Git reference could be overwritten at an
unexpected timing, for example, when a source or target branch is advanced.
In this case, the pipeline fails because of `fatal: reference is not a tree:` error,
which indicates that the checkout-SHA is not found in the merge ref.

2
doc/development/api_graphql_styleguide.md
View file

@ -548,7 +548,7 @@ found, we should raise a
`Gitlab::Graphql::Errors::ResourceNotAvailable` error. Which will be
correctly rendered to the clients.
## Gitlab's custom scalars
## GitLab's custom scalars
### `Types::TimeType`

24
doc/development/contributing/issue_workflow.md
View file

@ -40,17 +40,17 @@ scheduling into milestones. Labelling is a task for everyone.
Most issues will have labels for at least one of the following:
- Type: ~feature, ~bug, ~backstage, etc.
- Stage: ~"devops::plan", ~"devops::create", etc.
- Group: ~"group::source code", ~"group::knowledge", ~"group::editor", etc.
- Category: ~"Category:Code Analytics", ~"Category:DevOps Score", ~"Category:Templates", etc.
- Feature: ~wiki, ~ldap, ~api, ~issues, ~"merge requests", etc.
- Department: ~UX, ~Quality
- Team: ~"Technical Writing", ~Delivery
- Specialization: ~frontend, ~backend, ~documentation
- Release Scoping: ~Deliverable, ~Stretch, ~"Next Patch Release"
- Priority: ~P1, ~P2, ~P3, ~P4
- Severity: ~S1, ~S2, ~S3, ~S4
- Type: `~feature`, `~bug`, `~backstage`, etc.
- Stage: `~"devops::plan"`, `~"devops::create"`, etc.
- Group: `~"group::source code"`, `~"group::knowledge"`, `~"group::editor"`, etc.
- Category: `~"Category:Code Analytics"`, `~"Category:DevOps Score"`, `~"Category:Templates"`, etc.
- Feature: `~wiki`, `~ldap`, `~api`, `~issues`, `~"merge requests"`, etc.
- Department: `~UX`, `~Quality`
- Team: `~"Technical Writing"`, `~Delivery`
- Specialization: `~frontend`, `~backend`, `~documentation`
- Release Scoping: `~Deliverable`, `~Stretch`, `~"Next Patch Release"`
- Priority: `~P1`, `~P2`, `~P3`, `~P4`
- Severity: ~`S1`, `~S2`, `~S3`, `~S4`
All labels, their meaning and priority are defined on the
[labels page](https://gitlab.com/gitlab-org/gitlab-foss/-/labels).
@ -210,7 +210,7 @@ If you are an expert in a particular area, it makes it easier to find issues to
work on. You can also subscribe to those labels to receive an email each time an
issue is labeled with a feature label corresponding to your expertise.
Examples of feature labels are ~wiki, ~ldap, ~api, ~issues, ~"merge requests" etc.
Examples of feature labels are `~wiki`, `~ldap`, `~api`, `~issues`, `~"merge requests"` etc.
#### Naming and color convention

4
doc/development/documentation/index.md
View file

@ -41,7 +41,7 @@ However, anyone can contribute [documentation improvements](improvement-workflow
## Markdown and styles
[GitLab docs](https://gitlab.com/gitlab-org/gitlab-docs) uses [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown)
as its markdown rendering engine. See the [GitLab Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) for a complete Kramdown reference.
as its Markdown rendering engine. See the [GitLab Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) for a complete Kramdown reference.
Adhere to the [Documentation Style Guide](styleguide.md). If a style standard is missing, you are welcome to suggest one via a merge request.
@ -449,7 +449,7 @@ A file with `proselint` configuration must be placed in a
#### `markdownlint`
[`markdownlint`](https://github.com/DavidAnson/markdownlint) checks that markdown
[`markdownlint`](https://github.com/DavidAnson/markdownlint) checks that Markdown
syntax follows [certain rules](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules),
and is used by the [`docs-lint` test](#testing) with a [configuration file](#markdownlint-configuration).
Our [Documentation Style Guide](styleguide.md#markdown) and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/)

6
doc/development/documentation/site_architecture/index.md
View file

@ -128,9 +128,9 @@ We can then loop over the `versions` array with something like:
Note that the data file must have the `yaml` extension (not `yml`) and that
we reference the array with a symbol (`:versions`).
## Bumping versions of CSS and Javascript
## Bumping versions of CSS and JavaScript
Whenever the custom CSS and Javascript files under `content/assets/` change,
Whenever the custom CSS and JavaScript files under `content/assets/` change,
make sure to bump their version in the frontmatter. This method guarantees that
your changes will take effect by clearing the cache of previous files.
@ -180,7 +180,7 @@ for its search function. This is how it works:
1. On the docs side, we use a [docsearch layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/docsearch.html) which
is present on pretty much every page except <https://docs.gitlab.com/search/>,
which uses its [own layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/instantsearch.html). In those layouts,
there's a javascript snippet which initiates docsearch by using an API key
there's a JavaScript snippet which initiates docsearch by using an API key
and an index name (`gitlab`) that are needed for Algolia to show the results.
NOTE: **For GitLab employees:**

2
doc/development/documentation/site_architecture/release_process.md
View file

@ -117,7 +117,7 @@ version and rotates the old one:
There's a temporary hack for now:
1. Edit `content/404.html`, making sure all offline versions under
`content/_data/versions.yaml` are in the Javascript snippet at the end of
`content/_data/versions.yaml` are in the JavaScript snippet at the end of
the document.
1. **Update the `:latest` and `:archives` Docker images:**

20
doc/development/documentation/styleguide.md
View file

@ -102,7 +102,7 @@ Note that Kramdown-specific markup (e.g., `{:.class}`) will not render properly
Hard-coded HTML is valid, although it's discouraged to be used while we have `/help`. HTML is permitted as long as:
- There's no equivalent markup in markdown.
- There's no equivalent markup in Markdown.
- Advanced tables are necessary.
- Special styling is required.
- Reviewed and approved by a technical writer.
@ -245,7 +245,7 @@ Do not include the same information in multiple places. [Link to a SSOT instead.
## Text
- [Write in markdown](#markdown).
- [Write in Markdown](#markdown).
- Splitting long lines (preferably up to 100 characters) can make it easier to provide feedback on small chunks of text.
- Insert an empty line for new paragraphs.
- Use sentence case for titles, headings, labels, menu items, and buttons.
@ -453,7 +453,7 @@ to mix types, that is also possible, as long as you don't mix items at the same
## Quotes
Valid for markdown content only, not for frontmatter entries:
Valid for Markdown content only, not for frontmatter entries:
- Standard quotes: double quotes (`"`). Example: "This is wrapped in double quotes".
- Quote within a quote: double quotes (`"`) wrap single quotes (`'`). Example: "I am 'quoting' something within a quote".
@ -464,7 +464,7 @@ For other punctuation rules, please refer to the
## Headings
- Add **only one H1** in each document, by adding `#` at the beginning of
it (when using markdown). The `h1` will be the document `<title>`.
it (when using Markdown). The `h1` will be the document `<title>`.
- Start with an `h2` (`##`), and respect the order `h2` > `h3` > `h4` > `h5` > `h6`.
Never skip the hierarchy level, such as `h2` > `h4`
- Avoid putting numbers in headings. Numbers shift, hence documentation anchor
@ -490,7 +490,7 @@ For other punctuation rules, please refer to the
## Links
- Use inline link markdown markup `[Text](https://example.com)`.
- Use inline link Markdown markup `[Text](https://example.com)`.
It's easier to read, review, and maintain. **Do not** use `[Text][identifier]`.
- Use [meaningful anchor texts](https://www.futurehosting.com/blog/links-should-have-meaningful-anchor-text-heres-why/).
@ -533,7 +533,7 @@ For other punctuation rules, please refer to the
[issue tags](../../issues/tags.md#stages)
```
- Using the markdown extension is necessary for the [`/help`](index.md#gitlab-help)
- Using the Markdown extension is necessary for the [`/help`](index.md#gitlab-help)
section of GitLab.
### Links requiring permissions
@ -656,7 +656,7 @@ to readers.
To embed a video, follow the instructions below and make sure
you have your MR reviewed and approved by a technical writer.
1. Copy the code below and paste it into your markdown file.
1. Copy the code below and paste it into your Markdown file.
Leave a blank line above and below it. Do NOT edit the code
(don't remove or add any spaces, etc).
1. On YouTube, visit the video URL you want to display. Copy
@ -694,7 +694,7 @@ This is how it renders on the GitLab Docs site:
class is necessary to make sure the video is responsive and displays
nicely on different mobile devices.
> - The `<div class="video-fallback">` is a fallback necessary for GitLab's
`/help`, as GitLab's markdown processor does not support iframes. It's hidden on the docs site but will be displayed on GitLab's `/help`.
`/help`, as GitLab's Markdown processor does not support iframes. It's hidden on the docs site but will be displayed on GitLab's `/help`.
## Code blocks
@ -725,7 +725,7 @@ nicely on different mobile devices.
```
~~~
- To display raw markdown instead of rendered markdown, you can use triple backticks
- To display raw Markdown instead of rendered Markdown, you can use triple backticks
with `md`, like the `Markdown code` example above, unless you want to include triple
backticks in the code block as well. In that case, use triple tildes (`~~~`) instead.
- For a complete reference on code blocks, check the [Kramdown guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/#code-blocks).
@ -739,7 +739,7 @@ _Note that the alert boxes only work for one paragraph only. Multiple paragraphs
lists, headers, etc will not render correctly. For multiple lines, use blockquotes instead._
Alert boxes only render on the GitLab Docs site (<https://docs.gitlab.com>).
Within GitLab itself, they will appear as plain markdown text (like the examples
Within GitLab itself, they will appear as plain Markdown text (like the examples
above the rendered versions, below).
### Note

2
doc/development/feature_flags/controls.md
View file

@ -19,7 +19,7 @@ run:
## Where to run commands
To increase visibility, we recommend that GitLab team members run feature flag
related Chatops commands within certain slack channels based on the environment
related Chatops commands within certain Slack channels based on the environment
and related feature. For the [staging](https://staging.gitlab.com)
and [development](https://dev.gitlab.org) environments of GitLab.com,
the commands should run in a channel for the stage the feature is relevant too.

10
doc/development/internal_api.md
View file

@ -4,8 +4,8 @@ The internal API is used by different GitLab components, it can not be
used by other consumers. This documentation is intended for people
working on the GitLab codebase.
This documentation does not yet include the internal api used by
GitLab pages.
This documentation does not yet include the internal API used by
GitLab Pages.
## Authentication
@ -19,7 +19,7 @@ file, and include the token Base64 encoded in a `secret_token` param
or in the `Gitlab-Shared-Secret` header.
NOTE: **Note:**
The internal api used by GitLab pages uses a different kind of
The internal API used by GitLab Pages uses a different kind of
authentication.
## Git Authentication
@ -119,7 +119,7 @@ curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" --da
## Authorized Keys Check
This endpoint is called by the GitLab-shell authorized keys
check. Which is called by OpenSSH for [fast ssh key
check. Which is called by OpenSSH for [fast SSH key
lookup](../administration/operations/fast_ssh_key_lookup.md).
| Attribute | Type | Required | Description |
@ -292,7 +292,7 @@ Example response:
## PostReceive
Called from Gitaly after a receiving a push. This triggers the
`PostReceive`-worker in sidekiq, processes the passed push options and
`PostReceive`-worker in Sidekiq, processes the passed push options and
builds the response including messages that need to be displayed to
the user.

2
doc/development/merge_request_performance_guidelines.md
View file

@ -75,7 +75,7 @@ data set is for this feature to process, and what problems it might cause.
If you would think about the following example that puts
a strong emphasis of data set being processed.
The problem is simple: you want to filter a list of files from
some git repository. Your feature requests a list of all files
some Git repository. Your feature requests a list of all files
from the repository and perform search for the set of files.
As an author you should in context of that problem consider
the following:

6
doc/development/packages.md
View file

@ -90,14 +90,14 @@ model for that package type.
## File uploads
File uploads should be handled by GitLab workhorse using object accelerated uploads. What this means is that
File uploads should be handled by GitLab Workhorse using object accelerated uploads. What this means is that
the workhorse proxy that checks all incoming requests to GitLab will intercept the upload request,
upload the file, and forward a request to the main GitLab codebase only containing the metadata
and file location rather than the file itself. An overview of this process can be found in the
[development documentation](uploads.md#workhorse-object-storage-acceleration).
In terms of code, this means a route will need to be added to the
[gitlab-workhorse project](https://gitlab.com/gitlab-org/gitlab-workhorse) for each level of remote being added
[GitLab Workhorse project](https://gitlab.com/gitlab-org/gitlab-workhorse) for each level of remote being added
(instance, group, project). [This merge request](https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/412/diffs)
demonstrates adding an instance-level endpoint for Conan to workhorse. You can also see the Maven project level endpoint
implemented in the same file.
@ -164,7 +164,7 @@ process.
These changes represent all that is needed to deliver a minimally usable package management system.
1. Empty file structure (api file, base service for this package)
1. Empty file structure (API file, base service for this package)
1. Authentication system for 'logging in' to the package manager
1. Identify metadata and create applicable tables
1. Workhorse route for [object storage accelerated uploads](uploads.md#workhorse-object-storage-acceleration)

8
doc/development/pipelines.md
View file

@ -1,6 +1,6 @@
# Pipelines for the GitLab project
Pipelines for `gitlab-org/gitlab` and `gitlab-org/gitlab-foss` (as well as the
Pipelines for <https://gitlab.com/gitlab-org/gitlab> and <https://gitlab.com/gitlab-org/gitlab-foss> (as well as the
`dev` instance's mirrors) are configured in the usual
[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml)
which itself includes files under
@ -15,8 +15,8 @@ as much as possible.
The current stages are:
- `sync`: This stage is used to synchronize changes from gitlab-org/gitlab to
gitlab-org/gitlab-foss.
- `sync`: This stage is used to synchronize changes from <https://gitlab.com/gitlab-org/gitlab> to
<https://gitlab.com/gitlab-org/gitlab-foss>.
- `prepare`: This stage includes jobs that prepare artifacts that are needed by
jobs in subsequent stages.
- `quick-test`: This stage includes test jobs that should run first and fail the
@ -33,7 +33,7 @@ The current stages are:
- `post-test`: This stage includes jobs that build reports or gather data from
the previous stages' jobs (e.g. coverage, Knapsack metadata etc.).
- `pages`: This stage includes a job that deploys the various reports as
GitLab pages (e.g. <https://gitlab-org.gitlab.io/gitlab/coverage-ruby/>,
GitLab Pages (e.g. <https://gitlab-org.gitlab.io/gitlab/coverage-ruby/>,
<https://gitlab-org.gitlab.io/gitlab/coverage-javascript/>,
<https://gitlab-org.gitlab.io/gitlab/webpack-report/>).

2
doc/development/rake_tasks.md
View file

@ -96,7 +96,7 @@ In order to run the test you can use the following commands:
- `bin/rake spec:unit` to run the only the unit tests
- `bin/rake spec:integration` to run the only the integration tests
- `bin/rake spec:system` to run the only the system tests
- `bin/rake karma` to run the karma test suite
- `bin/rake karma` to run the Karma test suite
Note: `bin/rake spec` takes significant time to pass.
Instead of running full test suite locally you can save a lot of time by running

2
doc/development/sidekiq_style_guide.md
View file

@ -211,7 +211,7 @@ end
We use the following approach to determine whether a worker is CPU-bound:
- In the sidekiq structured JSON logs, aggregate the worker `duration` and
- In the Sidekiq structured JSON logs, aggregate the worker `duration` and
`cpu_s` fields.
- `duration` refers to the total job execution duration, in seconds
- `cpu_s` is derived from the

2
doc/integration/saml.md
View file

@ -541,7 +541,7 @@ args: {
}
```
GitLab will sign the request with the provided private key. GitLab will include the configured public x500 certificate in the metadata for your Identity Provider to validate the signature of the received request with. For more information on this option, see the [ruby-saml gem documentation](https://github.com/onelogin/ruby-saml/tree/v1.7.0). The `ruby-saml` gem is used by the [omniauth-saml gem](https://github.com/omniauth/omniauth-saml) to implement the client side of the SAML authentication.
GitLab will sign the request with the provided private key. GitLab will include the configured public x500 certificate in the metadata for your Identity Provider to validate the signature of the received request with. For more information on this option, see the [Ruby SAML gem documentation](https://github.com/onelogin/ruby-saml/tree/v1.7.0). The Ruby SAML gem is used by the [OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml) to implement the client side of the SAML authentication.
## Troubleshooting

2
doc/university/training/end-user/README.md
View file

@ -4,7 +4,7 @@ comments: false
# Training
This training material is the markdown used to generate training slides
This training material is the Markdown used to generate training slides
which can be found at [End User Slides](https://gitlab-org.gitlab.io/end-user-training-slides/#/)
through it's [RevealJS](https://gitlab.com/gitlab-org/end-user-training-slides)
project.

2
doc/university/training/index.md
View file

@ -5,7 +5,7 @@ type: index
# GitLab Training Material
All GitLab training material is stored in markdown format. Slides are
All GitLab training material is stored in Markdown format. Slides are
generated using [Deskset](https://www.deckset.com/).
All training material is open to public contribution.

64
doc/user/markdown.md
View file

@ -1,9 +1,9 @@
# GitLab Markdown
This markdown guide is **valid only for GitLab's internal markdown rendering system for entries and files**.
This Markdown guide is **valid only for GitLab's internal Markdown rendering system for entries and files**.
It is **not** valid for the [GitLab documentation website](https://docs.gitlab.com)
or [GitLab's main website](https://about.gitlab.com), as they both use
[Kramdown](https://kramdown.gettalong.org) as their markdown engine. The documentation
[Kramdown](https://kramdown.gettalong.org) as their Markdown engine. The documentation
website uses an extended Kramdown gem, [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown).
Consult the [GitLab Kramdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/)
for a complete Kramdown reference.
@ -40,7 +40,7 @@ repositories are also processed with CommonMark. As of 11.8, the [Redcarpet Ruby
has been removed and all issues and comments, including those from pre-11.1, are now processed
using the [CommonMark Ruby Library](https://github.com/gjtorikian/commonmarker).
The documentation website had its [markdown engine migrated from Redcarpet to Kramdown](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/108)
The documentation website had its [Markdown engine migrated from Redcarpet to Kramdown](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/108)
in October 2018.
You may have older issues, merge requests, or Markdown documents in your
@ -71,7 +71,7 @@ the top list item (`C` in this case):
- milk
NOTE: **Note:** We will flag any significant differences between Redcarpet and CommonMark
markdown in this document.
Markdown in this document.
If you have a large volume of Markdown files, it can be tedious to determine
if they will display correctly or not. You can use the
@ -81,13 +81,13 @@ differences between how RedCarpet and CommonMark render the files. It can give
an indication if anything needs to be changed - often nothing will need
to change.
### GFM extends standard markdown
### GFM extends standard Markdown
GitLab makes full use of the standard (CommonMark) formatting, but also includes additional
functionality useful for GitLab users.
It makes use of [new markdown features](#new-GFM-markdown-extensions),
not found in standard markdown:
It makes use of [new Markdown features](#new-GFM-markdown-extensions),
not found in standard Markdown:
- [Color "chips" written in HEX, RGB or HSL](#colors)
- [Diagrams and flowcharts](#diagrams-and-flowcharts)
@ -97,12 +97,12 @@ not found in standard markdown:
- [Math equations and symbols written in LaTeX](#math)
- [Special GitLab references](#special-gitlab-references)
- [Task Lists](#task-lists)
- [Wiki specific markdown](#wiki-specific-markdown)
- [Wiki specific Markdown](#wiki-specific-markdown)
It also has [extended markdown features](#standard-markdown-and-extensions-in-gitlab), without
changing how standard markdown is used:
It also has [extended Markdown features](#standard-markdown-and-extensions-in-gitlab), without
changing how standard Markdown is used:
| Standard markdown | Extended markdown in GitLab |
| Standard Markdown | Extended Markdown in GitLab |
| ------------------------------------- | ------------------------- |
| [blockquotes](#blockquotes) | [multiline blockquotes](#multiline-blockquote) |
| [code blocks](#code-spans-and-blocks) | [colored code and syntax highlighting](#colored-code-and-syntax-highlighting) |
@ -112,7 +112,7 @@ changing how standard markdown is used:
| [linebreaks](#line-breaks) | [more linebreak control](#newlines) |
| [links](#links) | [automatically linking URLs](#url-auto-linking) |
## New GFM markdown extensions
## New GFM Markdown extensions
### Colors
@ -263,7 +263,7 @@ this font installed by default.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/23331) in GitLab 11.6.
Front matter is metadata included at the beginning of a markdown document, preceding
Front matter is metadata included at the beginning of a Markdown document, preceding
its content. This data can be used by static site generators such as [Jekyll](https://jekyllrb.com/docs/front-matter/),
[Hugo](https://gohugo.io/content-management/front-matter/), and many other applications.
@ -534,9 +534,9 @@ This snippet links to `<wiki_root>/miscellaneous.md`:
Metric charts can be embedded within GitLab Flavored Markdown. See [Embedding Metrics within GitLab flavored Markdown](../user/project/integrations/prometheus.md#embedding-metric-charts-within-gitlab-flavored-markdown) for more details.
## Standard markdown and extensions in GitLab
## Standard Markdown and extensions in GitLab
All standard markdown formatting should work as expected within GitLab. Some standard
All standard Markdown formatting should work as expected within GitLab. Some standard
functionality is extended with additional features, without affecting the standard usage.
If a functionality is extended, the new option will be listed as a sub-section.
@ -565,7 +565,7 @@ Quote break.
> If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#multiline-blockquote).
GFM extends the standard markdown standard by also supporting multiline blockquotes
GFM extends the standard Markdown standard by also supporting multiline blockquotes
fenced by `>>>`:
```
@ -709,7 +709,7 @@ But let's throw in a <b>tag</b>.
### Emphasis
There are multiple ways to emphasize text in markdown. You can italicize, bold, strikethrough,
There are multiple ways to emphasize text in Markdown. You can italicize, bold, strikethrough,
as well as combine these emphasis styles together.
Examples:
@ -740,8 +740,8 @@ NOTE: **Note:** Strikethrough is not part of the core Markdown standard, but is
It is not usually useful to italicize just _part_ of a word, especially when you're
dealing with code and names that often appear with multiple underscores. As a result,
GFM extends the standard markdown standard by ignoring multiple underlines in words,
to allow better rendering of markdown documents discussing code:
GFM extends the standard Markdown standard by ignoring multiple underlines in words,
to allow better rendering of Markdown documents discussing code:
```md
perform_complicated_task
@ -773,7 +773,7 @@ do*this*and*do*that*and*another thing
### Footnotes
Footnotes add a link to a note rendered at the end of a markdown file:
Footnotes add a link to a note rendered at the end of a Markdown file:
```markdown
You can add footnotes to your text as follows.[^1]
@ -806,7 +806,7 @@ Alt-H2
#### Header IDs and links
GFM extends the standard markdown standard so that all Markdown-rendered headers automatically
GFM extends the standard Markdown standard so that all Markdown-rendered headers automatically
get IDs, which can be linked to, except in comments.
On hover, a link to those IDs becomes visible to make it easier to copy the link to
@ -925,7 +925,7 @@ Here's a sample audio clip:
### Inline HTML
> To see the markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#inline-html).
> To see the Markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#inline-html).
You can also use raw HTML in your Markdown, and it'll usually work pretty well.
@ -953,7 +953,7 @@ class for the list of allowed HTML tags and attributes. In addition to the defa
---
It is still possible to use markdown inside HTML tags, but only if the lines containing markdown
It is still possible to use Markdown inside HTML tags, but only if the lines containing Markdown
are separated into their own lines:
```html
@ -970,7 +970,7 @@ are separated into their own lines:
</dl>
```
<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, markdown will be fine in GitLab -->
<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, Markdown will be fine in GitLab -->
<dl>
<dt>Markdown in HTML</dt>
@ -986,7 +986,7 @@ are separated into their own lines:
#### Details and Summary
> To see the markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#details-and-summary).
> To see the Markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#details-and-summary).
Content can be collapsed using HTML's [`<details>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details)
and [`<summary>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary)
@ -1034,7 +1034,7 @@ PASTE LOGS HERE
</details>
````
<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, markdown will be fine in GitLab -->
<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, Markdown will be fine in GitLab -->
<details>
<summary>Click me to collapse/fold.</summary>
@ -1075,7 +1075,7 @@ in the *same paragraph*.
#### Newlines
GFM adheres to the markdown specification in how [paragraphs and line breaks are handled](https://spec.commonmark.org/current/).
GFM adheres to the Markdown specification in how [paragraphs and line breaks are handled](https://spec.commonmark.org/current/).
A paragraph is simply one or more consecutive lines of text, separated by one or
more blank lines (i.e. two newlines at the end of the first paragraph), as [explained above](#line-breaks).
@ -1122,7 +1122,7 @@ There are two ways to create links, inline-style and reference-style:
Using header ID anchors:
- This links to [a section on a different markdown page, using a "#" and the header ID](index.md#overview)
- This links to [a section on a different Markdown page, using a "#" and the header ID](index.md#overview)
- This links to [a different section on the same page, using a "#" and the header ID](#header-ids-and-links)
Using references:
@ -1145,7 +1145,7 @@ Some text to show that the reference links can follow later.
Using header ID anchors:
- This links to [a section on a different markdown page, using a "#" and the header ID](index.md#overview)
- This links to [a section on a different Markdown page, using a "#" and the header ID](index.md#overview)
- This links to [a different section on the same page, using a "#" and the header ID](#header-ids-and-links)
Using references:
@ -1163,7 +1163,7 @@ Some text to show that the reference links can follow later.
NOTE: **Note:** Relative links do not allow the referencing of project files in a wiki
page, or a wiki page in a project file. The reason for this is that a wiki is always
in a separate Git repository in GitLab. For example, `[I'm a reference-style link](style)`
will point the link to `wikis/style` only when the link is inside of a wiki markdown file.
will point the link to `wikis/style` only when the link is inside of a wiki Markdown file.
#### URL auto-linking
@ -1319,7 +1319,7 @@ Tables aren't part of the core Markdown spec, but they are part of GFM.
1. The first line contains the headers, separated by "pipes" (`|`).
1. The second line separates the headers from the cells, and must contain three or more dashes.
1. The third, and any following lines, contain the cell values.
- You **can't** have cells separated over many lines in the markdown, they must be kept to single lines,
- You **can't** have cells separated over many lines in the Markdown, they must be kept to single lines,
but they can be very long. You can also include HTML `<br>` tags to force newlines if needed.
- The cell sizes **don't** have to match each other. They are flexible, but must be separated
by pipes (`|`).
@ -1362,6 +1362,6 @@ to the sides of the "dash" lines in the second row. This will affect every cell
- This document leveraged heavily from the [Markdown-Cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
- The original [Markdown Syntax Guide](https://daringfireball.net/projects/markdown/syntax)
at Daring Fireball is an excellent resource for a detailed explanation of standard markdown.
at Daring Fireball is an excellent resource for a detailed explanation of standard Markdown.
- The detailed specification for CommonMark can be found in the [CommonMark Spec](https://spec.commonmark.org/current/)
- The [CommonMark Dingus](http://try.commonmark.org) is a handy tool for testing CommonMark syntax.