Commit 69131010 authored by Marcel Amirault's avatar Marcel Amirault

Merge branch 'docs-kramdown-fix' into 'master'

Fixing kramdown link errors in docs

See merge request gitlab-org/gitlab!21452
parents a0686586 ab8413fa
...@@ -35,7 +35,7 @@ The following guide assumes that: ...@@ -35,7 +35,7 @@ The following guide assumes that:
- You are using Omnibus and therefore you are using PostgreSQL 9.6 or later - You are using Omnibus and therefore you are using PostgreSQL 9.6 or later
which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/9.6/app-pgbasebackup.html) and improved which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/9.6/app-pgbasebackup.html) and improved
[Foreign Data Wrapper][FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support. [Foreign Data Wrapper](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support.
- You have a **primary** node already set up (the GitLab server you are - You have a **primary** node already set up (the GitLab server you are
replicating from), running Omnibus' PostgreSQL (or equivalent version), and replicating from), running Omnibus' PostgreSQL (or equivalent version), and
you have a new **secondary** server set up with the same versions of the OS, you have a new **secondary** server set up with the same versions of the OS,
......
...@@ -24,7 +24,7 @@ The author then adds a comment to this piece of code and adds a link to the issu ...@@ -24,7 +24,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
## How to create an A/B test ## How to create an A/B test
- [ ] Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb): - Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb):
```ruby ```ruby
EXPERIMENTS = { EXPERIMENTS = {
...@@ -40,7 +40,7 @@ The author then adds a comment to this piece of code and adds a link to the issu ...@@ -40,7 +40,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
}.freeze }.freeze
``` ```
- [ ] Use the experiment in a controller: - Use the experiment in a controller:
```ruby ```ruby
class RegistrationController < Applicationcontroller class RegistrationController < Applicationcontroller
...@@ -55,8 +55,8 @@ The author then adds a comment to this piece of code and adds a link to the issu ...@@ -55,8 +55,8 @@ The author then adds a comment to this piece of code and adds a link to the issu
end end
``` ```
- [ ] Track necessary events. See the [event tracking guide](../event_tracking/index.md) for details. - Track necessary events. See the [event tracking guide](../event_tracking/index.md) for details.
- [ ] After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel: - After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
``` ```
/chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true /chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true
......
...@@ -287,8 +287,6 @@ Example response: ...@@ -287,8 +287,6 @@ Example response:
} }
``` ```
## Notify Post Receive [UNUSED] ?
## PostReceive ## PostReceive
Called from Gitaly after a receiving a push. This triggers the Called from Gitaly after a receiving a push. This triggers the
...@@ -300,7 +298,7 @@ the user. ...@@ -300,7 +298,7 @@ the user.
|:----------|:-------|:---------|:------------| |:----------|:-------|:---------|:------------|
| `identifier` | string | yes | `user-[id]` or `key-[id]` Identifying the user performing the push | | `identifier` | string | yes | `user-[id]` or `key-[id]` Identifying the user performing the push |
| `gl_repository` | string | yes | identifier of the repository being pushed to | | `gl_repository` | string | yes | identifier of the repository being pushed to |
| `push_options` | [string] | no | array of push options | | `push_options` | string array | no | array of push options |
| `changes` | string | no | refs to be updated in the push in the format `oldrev newrev refname\n`. | | `changes` | string | no | refs to be updated in the push in the format `oldrev newrev refname\n`. |
``` ```
......
...@@ -50,7 +50,7 @@ review process a new change goes through. ...@@ -50,7 +50,7 @@ review process a new change goes through.
Including new features in patch releases is not possible as that would break [Semantic Versioning](https://semver.org/). Including new features in patch releases is not possible as that would break [Semantic Versioning](https://semver.org/).
Breaking [Semantic Versioning](https://semver.org/) has the following consequences for users that Breaking [Semantic Versioning](https://semver.org/) has the following consequences for users that
have to adhere to various internal requirements (e.g. org. compliance, verifying new features and similar): have to adhere to various internal requirements (for example, org. compliance, verifying new features, and similar):
1. Inability to quickly upgrade to leverage bug fixes included in patch versions. 1. Inability to quickly upgrade to leverage bug fixes included in patch versions.
1. Inability to quickly upgrade to leverage security fixes included in patch versions. 1. Inability to quickly upgrade to leverage security fixes included in patch versions.
...@@ -58,9 +58,12 @@ have to adhere to various internal requirements (e.g. org. compliance, verifying ...@@ -58,9 +58,12 @@ have to adhere to various internal requirements (e.g. org. compliance, verifying
In cases where a strategic user has a requirement to test a feature before it is In cases where a strategic user has a requirement to test a feature before it is
officially released, we can offer to create a Release Candidate (RC) version that will officially released, we can offer to create a Release Candidate (RC) version that will
include the specific feature. This should be needed only in extreme cases, and can be requested for consideration by raising an issue in [release/tasks] issue tracker. include the specific feature. This should be needed only in extreme cases, and can be requested for
It is important to note that the Release Candidate will also contain other consideration by raising an issue in the [release/tasks](https://gitlab.com/gitlab-org/release/tasks/issues/new?issuable_template=Backporting-request) issue tracker.
features and changes as it is not possible to easily isolate a specific feature (similar reasons as noted above). The Release Candidate will be no different than any code that is deployed to GitLab.com or is publicly accessible. It is important to note that the Release Candidate will also contain other features and changes as
it is not possible to easily isolate a specific feature (similar reasons as noted above). The
Release Candidate will be no different than any code that is deployed to GitLab.com or is publicly
accessible.
### Backporting to older releases ### Backporting to older releases
...@@ -68,11 +71,16 @@ Backporting to more than one stable release is reserved for [security releases]( ...@@ -68,11 +71,16 @@ Backporting to more than one stable release is reserved for [security releases](
In some cases however, we may need to backport *a bug fix* to more than one stable In some cases however, we may need to backport *a bug fix* to more than one stable
release, depending on the severity of the bug. release, depending on the severity of the bug.
Decision on whether backporting a change will be performed is done at the discretion of the [current release managers][release-managers], similar to what is described in the [managing bugs] process, based on *all* of the following: The decision on whether backporting a change will be performed is done at the discretion of the
[current release managers](https://about.gitlab.com/community/release-managers/), similar to what is
described in the [managing bugs](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#managing-bugs) process,
based on *all* of the following:
1. Estimated [severity][severity-labels] of the bug: Highest possible impact to users based on the current definition of severity. 1. Estimated [severity](../development/contributing/issue_workflow.md#severity-labels) of the bug:
Highest possible impact to users based on the current definition of severity.
1. Estimated [priority][priority-definition] of the bug: Immediate impact on all impacted users based on the above estimated severity. 1. Estimated [priority](../development/contributing/issue_workflow.md#priority-labels) of the bug:
Immediate impact on all impacted users based on the above estimated severity.
1. Potentially incurring data loss and/or security breach. 1. Potentially incurring data loss and/or security breach.
...@@ -83,7 +91,8 @@ the current stable stable release, and two previous monthly releases. ...@@ -83,7 +91,8 @@ the current stable stable release, and two previous monthly releases.
For instance, if we release `11.2.1` with a fix for a severe bug introduced in For instance, if we release `11.2.1` with a fix for a severe bug introduced in
`11.0.0`, we could backport the fix to a new `11.0.x`, and `11.1.x` patch release. `11.0.0`, we could backport the fix to a new `11.0.x`, and `11.1.x` patch release.
To request backporting to more than one stable release for consideration, raise an issue in [release/tasks] issue tracker. To request backporting to more than one stable release for consideration, raise an issue in the
[release/tasks](https://gitlab.com/gitlab-org/release/tasks/issues/new?issuable_template=Backporting-request) issue tracker.
### Security releases ### Security releases
...@@ -146,9 +155,3 @@ Please see the table below for some examples: ...@@ -146,9 +155,3 @@ Please see the table below for some examples:
More information about the release procedures can be found in our More information about the release procedures can be found in our
[release documentation](https://gitlab.com/gitlab-org/release/docs). You may also want to read our [release documentation](https://gitlab.com/gitlab-org/release/docs). You may also want to read our
[Responsible Disclosure Policy](https://about.gitlab.com/security/disclosure/). [Responsible Disclosure Policy](https://about.gitlab.com/security/disclosure/).
[release-managers]: https://about.gitlab.com/community/release-managers/
[priority-definition]: ../development/contributing/issue_workflow.md#priority-labels
[severity-labels]: ../development/contributing/issue_workflow.html#severity-labels
[managing bugs]: https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#managing-bugs
[release/tasks]: https://gitlab.com/gitlab-org/release/tasks/issues/new?issuable_template=Backporting-request
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment