diff options
Diffstat (limited to 'doc')
36 files changed, 137 insertions, 128 deletions
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index 2c9e1bc3cdf..b010a6425c8 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -631,7 +631,7 @@ and replication jobs will be created to replicate repository data to `internal_s #### Automatic failover When automatic failover is enabled, Praefect will do automatic detection of the health of internal Gitaly nodes. If the -primary has a certain amount of healthchecks fail, it will decide to promote one of the secondaries to be primary, and +primary has a certain amount of health checks fail, it will decide to promote one of the secondaries to be primary, and demote the primary to be a secondary. 1. To enable automatic failover, edit `/etc/gitlab/gitlab.rb`: diff --git a/doc/administration/troubleshooting/linux_cheat_sheet.md b/doc/administration/troubleshooting/linux_cheat_sheet.md index d53745c58b3..a03b8d1868e 100644 --- a/doc/administration/troubleshooting/linux_cheat_sheet.md +++ b/doc/administration/troubleshooting/linux_cheat_sheet.md @@ -215,7 +215,7 @@ Top 25 PIDs ``` Based on the summary, you can then view the details of syscalls made by one or more -procsses using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for +processes using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for a sorted list. `--stats` takes the same sorting and count options as summary. ```shell diff --git a/doc/administration/troubleshooting/ssl.md b/doc/administration/troubleshooting/ssl.md index ea17116d422..9474126e5c8 100644 --- a/doc/administration/troubleshooting/ssl.md +++ b/doc/administration/troubleshooting/ssl.md @@ -7,7 +7,7 @@ type: reference This page contains a list of common SSL-related errors and scenarios that you may face while working with GitLab. It should serve as an addition to the main SSL docs available here: -- [Omniibus SSL Configuration](https://docs.gitlab.com/omnibus/settings/ssl.html) +- [Omnibus SSL Configuration](https://docs.gitlab.com/omnibus/settings/ssl.html) - [Self-signed certificates or custom Certification Authorities for GitLab Runner](https://docs.gitlab.com/runner/configuration/tls-self-signed.html) - [Manually configuring HTTPS](https://docs.gitlab.com/omnibus/settings/nginx.html#manually-configuring-https) diff --git a/doc/api/group_badges.md b/doc/api/group_badges.md index 682270e094d..6d5961a7eb8 100644 --- a/doc/api/group_badges.md +++ b/doc/api/group_badges.md @@ -9,7 +9,7 @@ Badges support placeholders that will be replaced in real time in both the link - **%{project_path}**: will be replaced by the project path. - **%{project_id}**: will be replaced by the project id. - **%{default_branch}**: will be replaced by the project default branch. -- **%{commit_sha}**: will be replaced by the last project's commit sha. +- **%{commit_sha}**: will be replaced by the last project's commit SHA. Because these endpoints aren't inside a project's context, the information used to replace the placeholders will be from the first group's project by creation date. If the group hasn't got any project the original URL with the placeholders will be returned. diff --git a/doc/api/merge_request_context_commits.md b/doc/api/merge_request_context_commits.md index 4fbef3594d6..e9ba31401ef 100644 --- a/doc/api/merge_request_context_commits.md +++ b/doc/api/merge_request_context_commits.md @@ -51,7 +51,7 @@ POST /projects/:id/merge_requests/ | Attribute | Type | Required | Description | | --------- | ---- | -------- | ----------- | -| `commits` | string array | yes | The context commits' sha | +| `commits` | string array | yes | The context commits' SHA | ```json [ @@ -86,4 +86,4 @@ Parameters: | Attribute | Type | Required | Description | | --------- | ---- | -------- | ----------- | -| `commits` | string array | yes | The context commits' sha | +| `commits` | string array | yes | The context commits' SHA | diff --git a/doc/api/pipelines.md b/doc/api/pipelines.md index 55894a36147..9db7c1528ff 100644 --- a/doc/api/pipelines.md +++ b/doc/api/pipelines.md @@ -14,7 +14,7 @@ GET /projects/:id/pipelines | `scope` | string | no | The scope of pipelines, one of: `running`, `pending`, `finished`, `branches`, `tags` | | `status` | string | no | The status of pipelines, one of: `running`, `pending`, `success`, `failed`, `canceled`, `skipped`, `created` | | `ref` | string | no | The ref of pipelines | -| `sha` | string | no | The sha of pipelines | +| `sha` | string | no | The SHA of pipelines | | `yaml_errors`| boolean | no | Returns pipelines with invalid configurations | | `name`| string | no | The name of the user who triggered pipelines | | `username`| string | no | The username of the user who triggered pipelines | diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md index 4e2e61cfadf..c2d206dde54 100644 --- a/doc/ci/caching/index.md +++ b/doc/ci/caching/index.md @@ -265,7 +265,7 @@ test: Assuming your project is using [pip](https://pip.pypa.io/en/stable/) to install the Python dependencies, the following example defines `cache` globally so that -all jobs inherit it. Python libraries are installed in a virtualenv under `venv/`, +all jobs inherit it. Python libraries are installed in a virtual environment under `venv/`, pip's cache is defined under `.cache/pip/` and both are cached per-branch: ```yaml diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md index ea4ecbcca7f..37d6921c0a5 100644 --- a/doc/ci/jenkins/index.md +++ b/doc/ci/jenkins/index.md @@ -185,7 +185,7 @@ In self-managed GitLab instances, you can build an [Instance Template Repository Development teams across the whole organization can select templates from a dropdown menu. A group administrator is able to set a group to use as the source for the [custom project templates](../../user/admin_area/custom_project_templates.md), which can -be used by all projects in the group. An instance adminsitrator can set a group as +be used by all projects in the group. An instance administrator can set a group as the source for [instance project templates](../../user/group/custom_project_templates.md), which can be used by projects in that instance. diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md index d1749924ad3..4e02955bcea 100644 --- a/doc/ci/merge_request_pipelines/index.md +++ b/doc/ci/merge_request_pipelines/index.md @@ -7,40 +7,32 @@ last_update: 2019-07-03 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/15310) in GitLab 11.6. -Usually, when you create a new merge request, a pipeline runs with the -new change and checks if it's qualified to be merged into a target branch. This -pipeline should contain only necessary jobs for validating the new changes. -For example, unit tests, lint checks, and [Review Apps](../review_apps/index.md) -are often used in this cycle. +In a [basic configuration](../pipelines/pipeline_architectures.md), GitLab runs a pipeline each time +changes are pushed to a branch. The settings in the [`.gitlab-ci.yml`](../yaml/README.md) +file, including `rules`, `only`, and `except`, determine which jobs are added to a pipeline. -With pipelines for merge requests, you can design a specific pipeline structure -for when you are running a pipeline in a merge request. This -could be either adding or removing steps in the pipeline, to make sure that -your pipelines are as efficient as possible. +If you want the pipeline to run jobs **only** when merge requests are created or updated, +you can use *pipelines for merge requests*. -## Requirements and limitations +In the UI, these pipelines are labeled as `detached`. -Pipelines for merge requests have the following requirements and limitations: + + +A few notes: -- As of GitLab 11.10, pipelines for merge requests require GitLab Runner 11.9 - or higher due to the - [recent refspecs changes](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25504). - Pipelines for merge requests are incompatible with [CI/CD for external repositories](../ci_cd_for_external_repos/index.md). +- [Since GitLab 11.10](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25504), pipelines for merge requests require GitLab Runner 11.9. ## Configuring pipelines for merge requests To configure pipelines for merge requests, add the `only: [merge_requests]` parameter to -the jobs that you want to run only for merge requests. - -Then, when developers create or update merge requests, a pipeline runs -every time a commit is pushed to GitLab. +your `.gitlab-ci.yml` file. -NOTE: **Note**: -If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md), -pipelines for merge requests take precedence over the other regular pipelines. +In this example, the pipeline contains a `test` job that is configured to run on merge requests. -For example, consider the following [`.gitlab-ci.yml`](../yaml/README.md): +The `build` and `deploy` jobs don't have the `only: - merge_requests` parameter, +so they will not run on merge requests. ```yaml build: @@ -62,19 +54,14 @@ deploy: - master ``` -After the merge request is updated with new commits: +Whenever a merge request is updated with new commits: - GitLab detects that changes have occurred and creates a new pipeline for the merge request. - The pipeline fetches the latest code from the source branch and run tests against it. -In the above example, the pipeline contains only a `test` job. -Since the `build` and `deploy` jobs don't have the `only: [merge_requests]` parameter, -they will not run in the merge request. - -Pipelines tagged with the **detached** badge indicate that they were triggered -when a merge request was created or updated. For example: - - +NOTE: **Note**: +If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md), +pipelines for merge requests take precedence over the other regular pipelines. ## Pipelines for Merged Results **(PREMIUM)** @@ -129,10 +116,8 @@ Therefore: - Since `C` specifies that it should only run for merge requests, it will not run for any pipeline except a merge request pipeline. -As you can see, this will help you avoid a lot of boilerplate where you'd need -to add that `only:` rule to all of your jobs in order to make them always run. You -can use this for scenarios like having only pipelines with merge requests get a -Review App set up, helping to save resources. +This helps you avoid having to add the `only:` rule to all of your jobs +in order to make them always run. You can use this format to set up a Review App, helping to save resources. ## Excluding certain branches diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png Binary files differdeleted file mode 100644 index 8da2970ab5a..00000000000 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png +++ /dev/null diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md index ca980bb58c3..bab03f11aa8 100644 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md +++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md @@ -7,31 +7,32 @@ last_update: 2019-07-03 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/7380) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10. -It's possible for your source and target branches to diverge, which can result -in the scenario that source branch's pipeline was green, the target's pipeline was green, -but the combined output fails. - -By having your merge request pipeline automatically -create a new ref that contains the merge result of the source and target branch -(then running a pipeline on that ref), we can better test that the combined result -is also valid. - -GitLab can run pipelines for merge requests -on this merged result. That is, where the source and target branches are combined into a -new ref and a pipeline for this ref validates the result prior to merging. - - - -There are some cases where creating a combined ref is not possible or not wanted. -For example, a source branch that has conflicts with the target branch -or a merge request that is still in WIP status. In this case, -GitLab doesn't create a merge commit and the pipeline runs on source branch, instead, -which is a default behavior of [Pipelines for merge requests](../index.md) - i.e. `detached` label is shown to the pipelines. - -The detached state serves to warn you that you are working in a situation -subjected to merge problems, and helps to highlight that you should -get out of WIP status or resolve merge conflicts as soon as possible. +When you submit a merge request, you are requesting to merge changes from a +source branch into a target branch. By default, the CI pipeline runs jobs +against the source branch. + +With *pipelines for merged results*, the pipeline runs as if the changes from +the source branch have already been merged into the target branch. + +If the pipeline fails due to a problem in the target branch, you can wait until the +target is fixed and re-run the pipeline. +This new pipeline will run as if the source is merged with the updated target, and you +will not need to rebase. + +The pipeline does not automatically run when the target branch changes. Only changes +to the source branch trigger a new pipeline. If a long time has passed since the last successful +pipeline, you may want to re-run it before merge, to ensure that the source changes +can still be successfully merged into the target. + +When the merge request can't be merged, the pipeline runs against the source branch only. For example, when: + +- The target branch has changes that conflict with the changes in the source branch. +- The merge request is a + [work in progress](../../../user/project/merge_requests/work_in_progress_merge_requests.md). + +In these cases, the pipeline runs as a [pipeline for merge requests](../index.md) +and is labeled as `detached`. If these cases no longer exist, new pipelines will +again run against the merged results. ## Requirements and limitations diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md index 54eccc2919c..1859328247b 100644 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md +++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md @@ -8,31 +8,57 @@ last_update: 2019-07-03 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9186) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.0. > - [Squash and merge](../../../../user/project/merge_requests/squash_and_merge.md) support [introduced](https://gitlab.com/gitlab-org/gitlab/issues/13001) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.6. -[Pipelines for merged results](../index.md#pipelines-for-merged-results-premium) introduces -running a build on the result of the merged code prior to merging, as a way to keep master green. +When [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are +enabled, the pipeline jobs run as if the changes from your source branch have already +been merged into the target branch. -There's a scenario, however, for teams with a high number of changes in the target branch (typically master) where in many or even all cases, -by the time the merged code is validated another commit has made it to master, invalidating the merged result. -You'd need some kind of queuing, cancellation or retry mechanism for these scenarios -in order to ensure an orderly flow of changes into the target branch. +However, the target branch may be changing rapidly. When you're ready to merge, +if you haven't run the pipeline in a while, the target branch may have already changed. +Merging now could introduce breaking changes. -Each MR that joins a merge train joins as the last item in the train, -just as it works in the current state. However, instead of queuing and waiting, -each item takes the completed state of the previous (pending) merge ref, adds its own changes, -and starts the pipeline immediately in parallel under the assumption that everything is going to pass. +*Merge trains* can prevent this from happening. A merge train is a queued list of merge +requests, each waiting to be merged into the target branch. -This means that if all the pipelines in the train merge successfully, no pipeline time is wasted either queuing or retrying. -If the button is subsequently pressed in a different MR, instead of creating a new pipeline for the target branch, -it creates a new pipeline targeting the merge result of the previous MR plus the target branch. -Pipelines invalidated through failures are immediately canceled and requeued. +Each merge request on the train runs the merged results pipeline immediately before its +changes are merged into the target branch. If the pipeline fails, the breaking changes are +not merged, and the target branch is unaffected. + +Many merge requests can be added to the train. Each is trying to merge into the target branch. +Each request runs its own merged results pipeline, which includes the changes from +all of the other merge requests in *front* of it on the train. All the pipelines run +in parallel, to save time. + +If the pipeline for the merge request at the front of the train completes successfully, +the changes are merged into the target branch, and the other pipelines will continue to +run. + +If one of the pipelines fails, it is removed from the train, and all pipelines behind +it restart, but without the changes that were removed. + +Three merge requests (`A`, `B` and `C`) are added to a merge train in order, which +creates three merged results pipelines that run in parallel: + +1. The first pipeline runs on the changes from `A` combined with the target branch. +1. The second pipeline runs on the changes from `A` and `B` combined with the target branch. +1. The third pipeline runs on the changes from `A`, `B`, and `C` combined with the target branch. + +If the pipeline for `B` fails, it is removed from the train. The pipeline for +`C` restarts with the `A` and `C` changes, but without the `B` changes. + +If `A` then completes successfully, it merges into the target branch, and `C` continues +to run. If more merge requests are added to the train, they will now include the `A` +changes that are included in the target branch, and the `C` changes that are from +the merge request already in the train. + +Learn more about +[how merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/). ## Requirements and limitations Merge trains have the following requirements and limitations: -- GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher to run Merge Trains. -- This feature requires that - [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are +- GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher. +- [Pipelines for merged results](../index.md#pipelines-for-merged-results-premium) must be **configured properly**. - Each merge train can run a maximum of **twenty** pipelines in parallel. If more than twenty merge requests are added to the merge train, the merge requests @@ -70,7 +96,7 @@ current position will be displayed under the pipeline widget: ## Start/Add to merge train when pipeline succeeds You can add a merge request to a merge train only when the latest pipeline in the -merge request finished. While the pipeline is running or pending, you cannot add +merge request is finished. While the pipeline is running or pending, you cannot add the merge request to a train because the current change of the merge request may be broken thus it could affect the following merge requests. diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index 1c93527da0c..9844dca6bb9 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -537,7 +537,7 @@ Arguments can be defined within the resolver, those arguments will be made available to the fields using the resolver. When exposing a model that had an internal ID (`iid`), prefer using that in combination with the namespace path as arguments in a resolver over a database -ID. Othewise use a [globally unique ID](#exposing-global-ids). +ID. Otherwise use a [globally unique ID](#exposing-global-ids). We already have a `FullPathLoader` that can be included in other resolvers to quickly find Projects and Namespaces which will have a diff --git a/doc/development/architecture.md b/doc/development/architecture.md index d12d4b2029c..32626c19298 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -230,7 +230,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag - Process: `praefect` Praefect is a transparent proxy between each Git client and the Gitaly coordinating the replication of -repository updates to secondairy nodes. +repository updates to secondary nodes. #### GitLab Geo diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md index c91a9882bb0..3c7f0aa91d2 100644 --- a/doc/development/documentation/site_architecture/index.md +++ b/doc/development/documentation/site_architecture/index.md @@ -214,7 +214,7 @@ for its search function. This is how it works: 1. GitLab is a member of the [docsearch program](https://community.algolia.com/docsearch/#join-docsearch-program), which is the free tier of [Algolia](https://www.algolia.com/). -1. Algolia hosts a [doscsearch config](https://github.com/algolia/docsearch-configs/blob/master/configs/gitlab.json) +1. Algolia hosts a [DocSearch configuration](https://github.com/algolia/docsearch-configs/blob/master/configs/gitlab.json) for the GitLab docs site, and we've worked together to refine it. 1. That [config](https://community.algolia.com/docsearch/config-file.html) is parsed by their [crawler](https://community.algolia.com/docsearch/crawler-overview.html) diff --git a/doc/development/documentation/site_architecture/release_process.md b/doc/development/documentation/site_architecture/release_process.md index b81fdb66baf..45cf1a5ee76 100644 --- a/doc/development/documentation/site_architecture/release_process.md +++ b/doc/development/documentation/site_architecture/release_process.md @@ -11,7 +11,7 @@ The following Dockerfiles are used. | ---------- | ------------ | ----------- | | [`Dockerfile.bootstrap`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.bootstrap) | `gitlab-docs:bootstrap` | Contains all the dependencies that are needed to build the website. If the gems are updated and `Gemfile{,.lock}` changes, the image must be rebuilt. | | [`Dockerfile.builder.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.builder.onbuild) | `gitlab-docs:builder-onbuild` | Base image to build the docs website. It uses `ONBUILD` to perform all steps and depends on `gitlab-docs:bootstrap`. | -| [`Dockerfile.nginx.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.nginx.onbuild) | `gitlab-docs:nginx-onbuild` | Base image to use for building documentation archives. It uses `ONBUILD` to perform all required steps to copy the archive, and relies upon its parent `Dockerfile.builder.onbuild` that is invoked when building single documentation achives (see the `Dockerfile` of each branch. | +| [`Dockerfile.nginx.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.nginx.onbuild) | `gitlab-docs:nginx-onbuild` | Base image to use for building documentation archives. It uses `ONBUILD` to perform all required steps to copy the archive, and relies upon its parent `Dockerfile.builder.onbuild` that is invoked when building single documentation archives (see the `Dockerfile` of each branch. | | [`Dockerfile.archives`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.archives) | `gitlab-docs:archives` | Contains all the versions of the website in one archive. It copies all generated HTML files from every version in one location. | ## How to build the images diff --git a/doc/development/fe_guide/droplab/droplab.md b/doc/development/fe_guide/droplab/droplab.md index 1c6d895b3ab..4d7c882dc09 100644 --- a/doc/development/fe_guide/droplab/droplab.md +++ b/doc/development/fe_guide/droplab/droplab.md @@ -185,11 +185,11 @@ DropLab adds some CSS classes to help lower the barrier to integration. For example: -- The `droplab-item-selected` css class is added to items that have been selected +- The `droplab-item-selected` CSS class is added to items that have been selected either by a mouse click or by enter key selection. -- The `droplab-item-active` css class is added to items that have been selected +- The `droplab-item-active` CSS class is added to items that have been selected using arrow key navigation. -- You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example, +- You can add the `droplab-item-ignore` CSS class to any item that you do not want to be selectable. For example, an `<li class="divider"></li>` list divider element that should not be interactive. ## Internal events diff --git a/doc/development/fe_guide/style/vue.md b/doc/development/fe_guide/style/vue.md index b571707edfd..a7d8fc61752 100644 --- a/doc/development/fe_guide/style/vue.md +++ b/doc/development/fe_guide/style/vue.md @@ -75,7 +75,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. **Props Naming:** Avoid using DOM component prop names. 1. **Props Naming:** Use kebab-case instead of camelCase to provide props in templates. - ```javascript + ```html // bad <component class="btn"> @@ -97,7 +97,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. With more than one attribute, all attributes should be on a new line: - ```javascript + ```html // bad <component v-if="bar" param="baz" /> @@ -117,7 +117,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. The tag can be inline if there is only one attribute: - ```javascript + ```html // good <component bar="bar" /> @@ -238,7 +238,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. Shorthand `@` is preferable over `v-on` - ```javascript + ```html // bad <component v-on:click="eventHandler"/> @@ -248,7 +248,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. Shorthand `:` is preferable over `v-bind` - ```javascript + ```html // bad <component v-bind:class="btn"/> @@ -258,7 +258,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. Shorthand `#` is preferable over `v-slot` - ```javascript + ```html // bad <template v-slot:header></template> @@ -270,7 +270,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. Prefer self-closing component tags - ```javascript + ```html // bad <component></component> @@ -282,7 +282,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) 1. Prefer a component's kebab-cased name over other styles when using it in a template - ```javascript + ```html // bad <MyComponent /> @@ -372,7 +372,7 @@ Useful links: 1. Tooltips: Do not rely on `has-tooltip` class name for Vue components - ```javascript + ```html // bad <span class="has-tooltip" @@ -392,7 +392,7 @@ Useful links: 1. Don't change `data-original-title`. - ```javascript + ```html // bad <span data-original-title="tooltip text">Foo</span> diff --git a/doc/development/geo.md b/doc/development/geo.md index d3df2b421de..b922fdfa119 100644 --- a/doc/development/geo.md +++ b/doc/development/geo.md @@ -238,7 +238,7 @@ limited by its own restrictions. The credentials are configured as a FDW configuration and credentials definition are managed automatically by the Omnibus GitLab `gitlab-ctl reconfigure` command. -#### Refeshing the Foreign Tables +#### Refreshing the Foreign Tables Whenever a new Geo node is configured or the database schema changes on the **primary** node, you must refresh the foreign tables on the **secondary** node diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md index 95167c4adf1..d23c10f19d4 100644 --- a/doc/development/go_guide/index.md +++ b/doc/development/go_guide/index.md @@ -242,7 +242,7 @@ to make the test output easily readable. - Ideally, each test case should have a field with a unique identifier to use for naming subtests. In the Go standard library, this is commonly the `name string` field. -- Use `want`/`expect`/`actual` when you are specifcing something in the +- Use `want`/`expect`/`actual` when you are specifying something in the test case that will be used for assertion. #### Variable names diff --git a/doc/development/import_export.md b/doc/development/import_export.md index c969523cd40..5a7d176d1d3 100644 --- a/doc/development/import_export.md +++ b/doc/development/import_export.md @@ -1,6 +1,6 @@ # Import/Export development documentation -Troubleshooing and general development guidelines and tips for the [Import/Export feature](../user/project/settings/import_export.md). +Troubleshooting and general development guidelines and tips for the [Import/Export feature](../user/project/settings/import_export.md). <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> This document is originally based on the [Import/Export 201 presentation available on YouTube](https://www.youtube.com/watch?v=V3i1OfExotE). diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md index b9d287d11b0..60aec3a720a 100644 --- a/doc/development/internal_api.md +++ b/doc/development/internal_api.md @@ -187,8 +187,8 @@ Example response: ## Instance information -This get's some generic information about the instance. This is used -by Geo nodes to get information about eachother +This gets some generic information about the instance. This is used +by Geo nodes to get information about each other ```plaintext GET /internal/check diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md index 7f5ffe525af..d395bf13982 100644 --- a/doc/development/merge_request_performance_guidelines.md +++ b/doc/development/merge_request_performance_guidelines.md @@ -435,7 +435,7 @@ We can consider the following types of storages: ### Temporary storage The storage on production nodes is really sparse. The application should be built -in a way that accomodates running under very limited temporary storage. +in a way that accommodates running under very limited temporary storage. You can expect the system on which your code runs has a total of `1G-10G` of temporary storage. However, this storage is really shared across all jobs being run. If your job requires to use more than `100MB` of that space diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md index b44730b3c88..0ca25f43345 100644 --- a/doc/development/sidekiq_style_guide.md +++ b/doc/development/sidekiq_style_guide.md @@ -255,7 +255,7 @@ discouraged, and alternative approaches to processing the work should be considered. If a worker needs large amounts of both memory and CPU time, it should -be marked as memory-bound, due to the above restrction on high urgency +be marked as memory-bound, due to the above restriction on high urgency memory-bound workers. ## Declaring a Job as CPU-bound diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md index 2214d86542a..77a94de98c4 100644 --- a/doc/development/testing_guide/review_apps.md +++ b/doc/development/testing_guide/review_apps.md @@ -210,7 +210,7 @@ secure note named `gitlab-{ce,ee} Review App's root password`. If [Review App Stability](https://app.periscopedata.com/app/gitlab/496118/Engineering-Productivity-Sandbox?widget=6690556&udv=785399) dips this may be a signal that the `review-apps-ce/ee` cluster is unhealthy. -Leading indicators may be healthcheck failures leading to restarts or majority failure for Review App deployments. +Leading indicators may be health check failures leading to restarts or majority failure for Review App deployments. The [Review Apps Overview dashboard](https://app.google.stackdriver.com/dashboards/6798952013815386466?project=gitlab-review-apps&timeDomain=1d) aids in identifying load spikes on the cluster, and if nodes are problematic or the entire cluster is trending towards unhealthy. diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md index 60d6274cfce..40c44c974cc 100644 --- a/doc/integration/elasticsearch.md +++ b/doc/integration/elasticsearch.md @@ -631,7 +631,7 @@ Here are some common pitfalls and how to overcome them: Gitlab::Elastic::Indexer::Error: time="2020-01-23T09:13:00Z" level=fatal msg="health check timeout: no Elasticsearch node available" ``` - You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticseach Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be acceped as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a). + You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticseach Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a). Once you have corrected the formatting of the URL, delete the index (via the [dedicated rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index). ### Reverting to basic search diff --git a/doc/integration/salesforce.md b/doc/integration/salesforce.md index 5272e9fd5e5..64eac2f9e66 100644 --- a/doc/integration/salesforce.md +++ b/doc/integration/salesforce.md @@ -23,7 +23,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create - **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`. - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (OpenID)** to the right column. -  +  1. Click **Save**. diff --git a/doc/integration/vault.md b/doc/integration/vault.md index c216fdfca4a..b1cc89e736d 100644 --- a/doc/integration/vault.md +++ b/doc/integration/vault.md @@ -103,7 +103,7 @@ The following assumes you already have Vault installed and running. vault login -method=oidc port=8250 role=demo ``` - Here is a short explaination of what this command does: + Here is a short explanation of what this command does: 1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with. 1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`. diff --git a/doc/topics/web_application_firewall/quick_start_guide.md b/doc/topics/web_application_firewall/quick_start_guide.md index 417e1973b87..13871eea4af 100644 --- a/doc/topics/web_application_firewall/quick_start_guide.md +++ b/doc/topics/web_application_firewall/quick_start_guide.md @@ -238,7 +238,7 @@ $ kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-a } ``` -You can see that ModSecurity logs the suspicous behavior. By sending a request +You can see that ModSecurity logs the suspicious behavior. By sending a request with the `User Agent: absinthe` header, which [absinthe](https://github.com/cameronhotchkies/Absinthe), a tool for testing for SQL injections uses, we can detect that someone was searching for vulnerabilities on our system. Detecting scanners is useful, because we can learn if someone is trying to exploit our system. diff --git a/doc/university/process/README.md b/doc/university/process/README.md index a9835ce879c..0b7fa467230 100644 --- a/doc/university/process/README.md +++ b/doc/university/process/README.md @@ -22,9 +22,9 @@ please submit a merge request to add an upcoming class, assign to 1. To allow people to contribute all content should be in Git. 1. The content can go in a subdirectory under `/doc/university/`. 1. To make, view or modify the slides of the classes use [Deckset](https://www.deckset.com) - or [RevealJS](https://revealjs.com/#/). Do not use Powerpoint or Google + or [RevealJS](https://revealjs.com/#/). Do not use PowerPoint or Google Slides since this prevents everyone from contributing. -1. Please upload any video recordings to our Youtube channel. We prefer them to +1. Please upload any video recordings to our YouTube channel. We prefer them to be public, if needed they can be unlisted but if so they should be linked from this page. 1. Please create a merge request and assign to [Erica](https://gitlab.com/Erica). diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md index f77d0d797dc..ead096b5a47 100644 --- a/doc/user/discussions/index.md +++ b/doc/user/discussions/index.md @@ -447,7 +447,7 @@ instead of the usual three.  - + ### Configure the commit message for applied Suggestions diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md index 0f3eea14efc..cd8f7e049a3 100644 --- a/doc/user/project/clusters/serverless/aws.md +++ b/doc/user/project/clusters/serverless/aws.md @@ -368,7 +368,7 @@ variables. To set these: 1. Navigate to the project's **{settings}** **Settings > CI / CD**. -1. Expand the **Variables** section and create entires for `AWS_ACCESS_KEY_ID` and +1. Expand the **Variables** section and create entries for `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`. 1. Mask the credentials so they do not show in logs using the **Masked** toggle. diff --git a/doc/user/project/issues/csv_export.md b/doc/user/project/issues/csv_export.md index fdc8246d102..8de0f038881 100644 --- a/doc/user/project/issues/csv_export.md +++ b/doc/user/project/issues/csv_export.md @@ -61,7 +61,7 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot | Assignee Username | Username of the author, with the `@` symbol omitted | | Confidential | `Yes` or `No` | | Locked | `Yes` or `No` | -| Due Date | Formated as `YYYY-MM-DD` | +| Due Date | Formatted as `YYYY-MM-DD` | | Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | | Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | | Milestone | Title of the issue milestone | diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md index cd106b062f4..a6ef5f5cfcc 100644 --- a/doc/user/project/labels.md +++ b/doc/user/project/labels.md @@ -175,7 +175,7 @@ For example, `workflow::backend::review` and `workflow::backend::development` ar scoped labels, but they **can't** exist on the same issue at the same time, as they both share the same scope, `workflow::backend`. -Addtionally, `workflow::backend::review` and `workflow::frontend::review` are valid +Additionally, `workflow::backend::review` and `workflow::frontend::review` are valid scoped labels, and they **can** exist on the same issue at the same time, as they both have different scopes, `workflow::frontend` and `workflow::backend`. diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md index 37b8b8c7b02..fe7c2c2757b 100644 --- a/doc/user/project/merge_requests/test_coverage_visualization.md +++ b/doc/user/project/merge_requests/test_coverage_visualization.md @@ -22,7 +22,7 @@ You can specify one or more coverage reports to collect, including wildcard path GitLab will then take the coverage information in all the files and combine it together. -For the coverage analysis to work, you have to provide a properly formated +For the coverage analysis to work, you have to provide a properly formatted [Cobertura XML](https://cobertura.github.io/cobertura/) report to [`artifacts:reports:cobertura`](../../../ci/yaml/README.md#artifactsreportscobertura). This format was originally developed for Java, but most coverage analysis frameworks diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md index a9e5d66aa6d..8680da3ad01 100644 --- a/doc/user/project/web_ide/index.md +++ b/doc/user/project/web_ide/index.md @@ -46,11 +46,8 @@ Single file editing is based on the [Ace Editor](https://ace.c9.io). ## Commit changes > - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4539) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4 and [brought to GitLab Core](https://gitlab.com/gitlab-org/gitlab-foss/issues/44157) in 10.7. -> - From [GitLab 12.7 onwards](https://gitlab.com/gitlab-org/gitlab/issues/33441), -files were automatically staged. -> - From [GitLab 12.9 onwards](https://gitlab.com/gitlab-org/gitlab/-/issues/196609), support for staging files was removed -to prevent loss of unstaged data. All your current changes necessarily have to be -committed or discarded. +> - From [GitLab 12.7 onward](https://gitlab.com/gitlab-org/gitlab/issues/33441), files were automatically staged. +> - From [GitLab 12.9 onward](https://gitlab.com/gitlab-org/gitlab/-/issues/196609), support for staging files was removed to prevent loss of unstaged data. All your current changes necessarily have to be committed or discarded. After making your changes, click the **Commit** button on the bottom-left to review the list of changed files. |
