@@ -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
-[ ] 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
EXPERIMENTS={
...
...
@@ -40,7 +40,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
}.freeze
```
-[ ] Use the experiment in a controller:
- Use the experiment in a controller:
```ruby
classRegistrationController<Applicationcontroller
...
...
@@ -55,8 +55,8 @@ The author then adds a comment to this piece of code and adds a link to the issu
end
```
-[ ] 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:
- 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:
```
/chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true
@@ -11,7 +11,7 @@ easy to maintain, and performant for the end-user.
### Utility Classes
As part of the effort for [cleaning up our CSS and moving our components into GitLab-UI](https://gitlab.com/groups/gitlab-org/-/epics/950)
As part of the effort for [cleaning up our CSS and moving our components into gitlab-ui](https://gitlab.com/groups/gitlab-org/-/epics/950)
led by the [GitLab UI WG](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/20623) we prefer the use of utility classes over adding new CSS. However, complex CSS can be addressed by adding component classes.
We use ESLint to encapsulate and enforce frontend code standards. Our configuration may be found in the [gitlab-eslint-config](https://gitlab.com/gitlab-org/gitlab-eslint-config) project.
We use ESLint to encapsulate and enforce frontend code standards. Our configuration may be found in the [`gitlab-eslint-config`](https://gitlab.com/gitlab-org/gitlab-eslint-config) project.
@@ -138,7 +138,7 @@ configured or there was an error reporting the status via the API.
### Merge Request event does not trigger a Jenkins Pipeline
Check the **/var/log/gitlab/gitlab-rails/production.log** file for messages like:
Check the `/var/log/gitlab/gitlab-rails/production.log` file for messages like:
```plaintext
WebHook Error => Net::ReadTimeout
...
...
@@ -157,7 +157,7 @@ which is set to 10 seconds by default.
To fix this the `gitlab_rails['webhook_timeout']` value will need to be increased
in the `gitlab.rb` config file, followed by the [`gitlab-ctl reconfigure` command](../administration/restart_gitlab.md).
If you don't find the errors above, but do find *duplicate* entries like below (in **/var/log/gitlab/gitlab-rail**), this
If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this
could also indicate that [webhook requests are timing out](../user/project/integrations/webhooks.md#receiving-duplicate-or-multiple-webhook-requests-triggered-by-one-event):
@@ -42,7 +42,7 @@ The following assumes you already have Vault installed and running.
1.**Write the OIDC config:**
Next, Vault needs to be given the application ID and secret generated by Gitlab.
Next, Vault needs to be given the application ID and secret generated by GitLab.
In the terminal session, run the following command to give Vault access to the GitLab application you've just created with an OpenID scope. This allows Vault to authenticate through GitLab.
@@ -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/).
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 security fixes included in patch versions.
...
...
@@ -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
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.
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.
include the specific feature. This should be needed only in extreme cases, and can be requested for
consideration by raising an issue in the [release/tasks](https://gitlab.com/gitlab-org/release/tasks/issues/new?issuable_template=Backporting-request) issue tracker.
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
...
...
@@ -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
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.
...
...
@@ -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
`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
