Commit dddde902 authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 101c30f4
...@@ -631,7 +631,7 @@ and replication jobs will be created to replicate repository data to `internal_s ...@@ -631,7 +631,7 @@ and replication jobs will be created to replicate repository data to `internal_s
#### Automatic failover #### Automatic failover
When automatic failover is enabled, Praefect will do automatic detection of the health of internal Gitaly nodes. If the 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. demote the primary to be a secondary.
1. To enable automatic failover, edit `/etc/gitlab/gitlab.rb`: 1. To enable automatic failover, edit `/etc/gitlab/gitlab.rb`:
......
...@@ -215,7 +215,7 @@ Top 25 PIDs ...@@ -215,7 +215,7 @@ Top 25 PIDs
``` ```
Based on the summary, you can then view the details of syscalls made by one or more 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. a sorted list. `--stats` takes the same sorting and count options as summary.
```shell ```shell
......
...@@ -7,7 +7,7 @@ type: reference ...@@ -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. 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: 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) - [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) - [Manually configuring HTTPS](https://docs.gitlab.com/omnibus/settings/nginx.html#manually-configuring-https)
......
...@@ -9,7 +9,7 @@ Badges support placeholders that will be replaced in real time in both the link ...@@ -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_path}**: will be replaced by the project path.
- **%{project_id}**: will be replaced by the project id. - **%{project_id}**: will be replaced by the project id.
- **%{default_branch}**: will be replaced by the project default branch. - **%{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 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. 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.
......
...@@ -51,7 +51,7 @@ POST /projects/:id/merge_requests/ ...@@ -51,7 +51,7 @@ POST /projects/:id/merge_requests/
| Attribute | Type | Required | Description | | Attribute | Type | Required | Description |
| --------- | ---- | -------- | ----------- | | --------- | ---- | -------- | ----------- |
| `commits` | string array | yes | The context commits' sha | | `commits` | string array | yes | The context commits' SHA |
```json ```json
[ [
...@@ -86,4 +86,4 @@ Parameters: ...@@ -86,4 +86,4 @@ Parameters:
| Attribute | Type | Required | Description | | Attribute | Type | Required | Description |
| --------- | ---- | -------- | ----------- | | --------- | ---- | -------- | ----------- |
| `commits` | string array | yes | The context commits' sha | | `commits` | string array | yes | The context commits' SHA |
...@@ -14,7 +14,7 @@ GET /projects/:id/pipelines ...@@ -14,7 +14,7 @@ GET /projects/:id/pipelines
| `scope` | string | no | The scope of pipelines, one of: `running`, `pending`, `finished`, `branches`, `tags` | | `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` | | `status` | string | no | The status of pipelines, one of: `running`, `pending`, `success`, `failed`, `canceled`, `skipped`, `created` |
| `ref` | string | no | The ref of pipelines | | `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 | | `yaml_errors`| boolean | no | Returns pipelines with invalid configurations |
| `name`| string | no | The name of the user who triggered pipelines | | `name`| string | no | The name of the user who triggered pipelines |
| `username`| string | no | The username of the user who triggered pipelines | | `username`| string | no | The username of the user who triggered pipelines |
......
...@@ -265,7 +265,7 @@ test: ...@@ -265,7 +265,7 @@ test:
Assuming your project is using [pip](https://pip.pypa.io/en/stable/) to install 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 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: pip's cache is defined under `.cache/pip/` and both are cached per-branch:
```yaml ```yaml
......
...@@ -185,7 +185,7 @@ In self-managed GitLab instances, you can build an [Instance Template Repository ...@@ -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. 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 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 [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), the source for [instance project templates](../../user/group/custom_project_templates.md),
which can be used by projects in that instance. which can be used by projects in that instance.
......
...@@ -7,40 +7,32 @@ last_update: 2019-07-03 ...@@ -7,40 +7,32 @@ last_update: 2019-07-03
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/15310) in GitLab 11.6. > [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 In a [basic configuration](../pipelines/pipeline_architectures.md), GitLab runs a pipeline each time
new change and checks if it's qualified to be merged into a target branch. This changes are pushed to a branch. The settings in the [`.gitlab-ci.yml`](../yaml/README.md)
pipeline should contain only necessary jobs for validating the new changes. file, including `rules`, `only`, and `except`, determine which jobs are added to a pipeline.
For example, unit tests, lint checks, and [Review Apps](../review_apps/index.md)
are often used in this cycle.
With pipelines for merge requests, you can design a specific pipeline structure If you want the pipeline to run jobs **only** when merge requests are created or updated,
for when you are running a pipeline in a merge request. This you can use *pipelines for merge requests*.
could be either adding or removing steps in the pipeline, to make sure that
your pipelines are as efficient as possible.
## Requirements and limitations In the UI, these pipelines are labeled as `detached`.
Pipelines for merge requests have the following requirements and limitations: ![Merge request page](img/merge_request.png)
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 - Pipelines for merge requests are incompatible with
[CI/CD for external repositories](../ci_cd_for_external_repos/index.md). [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 ## Configuring pipelines for merge requests
To configure pipelines for merge requests, add the `only: [merge_requests]` parameter to To configure pipelines for merge requests, add the `only: [merge_requests]` parameter to
the jobs that you want to run only for merge requests. your `.gitlab-ci.yml` file.
Then, when developers create or update merge requests, a pipeline runs
every time a commit is pushed to GitLab.
NOTE: **Note**: In this example, the pipeline contains a `test` job that is configured to run on merge requests.
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.
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 ```yaml
build: build:
...@@ -62,19 +54,14 @@ deploy: ...@@ -62,19 +54,14 @@ deploy:
- master - 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. - 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. - 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. NOTE: **Note**:
Since the `build` and `deploy` jobs don't have the `only: [merge_requests]` parameter, If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
they will not run in the merge request. pipelines for merge requests take precedence over the other regular pipelines.
Pipelines tagged with the **detached** badge indicate that they were triggered
when a merge request was created or updated. For example:
![Merge request page](img/merge_request.png)
## Pipelines for Merged Results **(PREMIUM)** ## Pipelines for Merged Results **(PREMIUM)**
...@@ -129,10 +116,8 @@ Therefore: ...@@ -129,10 +116,8 @@ Therefore:
- Since `C` specifies that it should only run for merge requests, it will not run for any pipeline - Since `C` specifies that it should only run for merge requests, it will not run for any pipeline
except a merge request pipeline. except a merge request pipeline.
As you can see, this will help you avoid a lot of boilerplate where you'd need This helps you avoid having to add the `only:` rule to all of your jobs
to add that `only:` rule to all of your jobs in order to make them always run. You in order to make them always run. You can use this format to set up a Review App, helping to save resources.
can use this for scenarios like having only pipelines with merge requests get a
Review App set up, helping to save resources.
## Excluding certain branches ## Excluding certain branches
......
...@@ -7,31 +7,32 @@ last_update: 2019-07-03 ...@@ -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. > [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 When you submit a merge request, you are requesting to merge changes from a
in the scenario that source branch's pipeline was green, the target's pipeline was green, source branch into a target branch. By default, the CI pipeline runs jobs
but the combined output fails. against the source branch.
By having your merge request pipeline automatically With *pipelines for merged results*, the pipeline runs as if the changes from
create a new ref that contains the merge result of the source and target branch the source branch have already been merged into the target branch.
(then running a pipeline on that ref), we can better test that the combined result
is also valid. 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.
GitLab can run pipelines for merge requests This new pipeline will run as if the source is merged with the updated target, and you
on this merged result. That is, where the source and target branches are combined into a will not need to rebase.
new ref and a pipeline for this ref validates the result prior to merging.
The pipeline does not automatically run when the target branch changes. Only changes
![Merge request pipeline as the head pipeline](img/merged_result_pipeline_v12_3.png) 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
There are some cases where creating a combined ref is not possible or not wanted. can still be successfully merged into the target.
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, When the merge request can't be merged, the pipeline runs against the source branch only. For example, when:
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) - The target branch has changes that conflict with the changes in the source branch.
i.e. `detached` label is shown to the pipelines. - The merge request is a
[work in progress](../../../user/project/merge_requests/work_in_progress_merge_requests.md).
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 In these cases, the pipeline runs as a [pipeline for merge requests](../index.md)
get out of WIP status or resolve merge conflicts as soon as possible. and is labeled as `detached`. If these cases no longer exist, new pipelines will
again run against the merged results.
## Requirements and limitations ## Requirements and limitations
......
...@@ -8,31 +8,57 @@ last_update: 2019-07-03 ...@@ -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. > - [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. > - [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 When [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are
running a build on the result of the merged code prior to merging, as a way to keep master green. 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, However, the target branch may be changing rapidly. When you're ready to merge,
by the time the merged code is validated another commit has made it to master, invalidating the merged result. if you haven't run the pipeline in a while, the target branch may have already changed.
You'd need some kind of queuing, cancellation or retry mechanism for these scenarios Merging now could introduce breaking changes.
in order to ensure an orderly flow of changes into the target branch.
Each MR that joins a merge train joins as the last item in the train, *Merge trains* can prevent this from happening. A merge train is a queued list of merge
just as it works in the current state. However, instead of queuing and waiting, requests, each waiting to be merged into the target branch.
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.
This means that if all the pipelines in the train merge successfully, no pipeline time is wasted either queuing or retrying. Each merge request on the train runs the merged results pipeline immediately before its
If the button is subsequently pressed in a different MR, instead of creating a new pipeline for the target branch, changes are merged into the target branch. If the pipeline fails, the breaking changes are
it creates a new pipeline targeting the merge result of the previous MR plus the target branch. not merged, and the target branch is unaffected.
Pipelines invalidated through failures are immediately canceled and requeued.
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 ## Requirements and limitations
Merge trains have the following 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. - GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher.
- This feature requires that - [Pipelines for merged results](../index.md#pipelines-for-merged-results-premium) must be
[pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are
**configured properly**. **configured properly**.
- Each merge train can run a maximum of **twenty** pipelines in parallel. - 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 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: ...@@ -70,7 +96,7 @@ current position will be displayed under the pipeline widget:
## Start/Add to merge train when pipeline succeeds ## 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 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 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. be broken thus it could affect the following merge requests.
......
...@@ -537,7 +537,7 @@ Arguments can be defined within the resolver, those arguments will be ...@@ -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 made available to the fields using the resolver. When exposing a model
that had an internal ID (`iid`), prefer using that in combination with that had an internal ID (`iid`), prefer using that in combination with
the namespace path as arguments in a resolver over a database 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 We already have a `FullPathLoader` that can be included in other
resolvers to quickly find Projects and Namespaces which will have a resolvers to quickly find Projects and Namespaces which will have a
......
...@@ -230,7 +230,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag ...@@ -230,7 +230,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
- Process: `praefect` - Process: `praefect`
Praefect is a transparent proxy between each Git client and the Gitaly coordinating the replication of 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 #### GitLab Geo
......
...@@ -214,7 +214,7 @@ for its search function. This is how it works: ...@@ -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), 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/). 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. 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 1. That [config](https://community.algolia.com/docsearch/config-file.html) is
parsed by their [crawler](https://community.algolia.com/docsearch/crawler-overview.html) parsed by their [crawler](https://community.algolia.com/docsearch/crawler-overview.html)
......
...@@ -11,7 +11,7 @@ The following Dockerfiles are used. ...@@ -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.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.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. | | [`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 ## How to build the images
......
...@@ -185,11 +185,11 @@ DropLab adds some CSS classes to help lower the barrier to integration. ...@@ -185,11 +185,11 @@ DropLab adds some CSS classes to help lower the barrier to integration.
For example: 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. 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. 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. an `<li class="divider"></li>` list divider element that should not be interactive.
## Internal events ## Internal events
......
...@@ -75,7 +75,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -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:** Avoid using DOM component prop names.
1. **Props Naming:** Use kebab-case instead of camelCase to provide props in templates. 1. **Props Naming:** Use kebab-case instead of camelCase to provide props in templates.
```javascript ```html
// bad // bad
<component class="btn"> <component class="btn">
...@@ -97,7 +97,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -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: 1. With more than one attribute, all attributes should be on a new line:
```javascript ```html
// bad // bad
<component v-if="bar" <component v-if="bar"
param="baz" /> param="baz" />
...@@ -117,7 +117,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -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: 1. The tag can be inline if there is only one attribute:
```javascript ```html
// good // good
<component bar="bar" /> <component bar="bar" />
...@@ -238,7 +238,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -238,7 +238,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
1. Shorthand `@` is preferable over `v-on` 1. Shorthand `@` is preferable over `v-on`
```javascript ```html
// bad // bad
<component v-on:click="eventHandler"/> <component v-on:click="eventHandler"/>
...@@ -248,7 +248,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -248,7 +248,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
1. Shorthand `:` is preferable over `v-bind` 1. Shorthand `:` is preferable over `v-bind`
```javascript ```html
// bad // bad
<component v-bind:class="btn"/> <component v-bind:class="btn"/>
...@@ -258,7 +258,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -258,7 +258,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
1. Shorthand `#` is preferable over `v-slot` 1. Shorthand `#` is preferable over `v-slot`
```javascript ```html
// bad // bad
<template v-slot:header></template> <template v-slot:header></template>
...@@ -270,7 +270,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -270,7 +270,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
1. Prefer self-closing component tags 1. Prefer self-closing component tags
```javascript ```html
// bad // bad
<component></component> <component></component>
...@@ -282,7 +282,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -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 1. Prefer a component's kebab-cased name over other styles when using it in a template
```javascript ```html
// bad // bad
<MyComponent /> <MyComponent />
...@@ -372,7 +372,7 @@ Useful links: ...@@ -372,7 +372,7 @@ Useful links:
1. Tooltips: Do not rely on `has-tooltip` class name for Vue components 1. Tooltips: Do not rely on `has-tooltip` class name for Vue components
```javascript ```html
// bad // bad
<span <span
class="has-tooltip" class="has-tooltip"
...@@ -392,7 +392,7 @@ Useful links: ...@@ -392,7 +392,7 @@ Useful links:
1. Don't change `data-original-title`. 1. Don't change `data-original-title`.
```javascript ```html
// bad // bad
<span data-original-title="tooltip text">Foo</span> <span data-original-title="tooltip text">Foo</span>
......
...@@ -238,7 +238,7 @@ limited by its own restrictions. The credentials are configured as a ...@@ -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 FDW configuration and credentials definition are managed automatically by the
Omnibus GitLab `gitlab-ctl reconfigure` command. 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 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 **primary** node, you must refresh the foreign tables on the **secondary** node
......
...@@ -242,7 +242,7 @@ to make the test output easily readable. ...@@ -242,7 +242,7 @@ to make the test output easily readable.
- Ideally, each test case should have a field with a unique identifier - 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 to use for naming subtests. In the Go standard library, this is commonly the
`name string` field. `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. test case that will be used for assertion.
#### Variable names #### Variable names
......
# Import/Export development documentation # 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). <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).
......
...@@ -187,8 +187,8 @@ Example response: ...@@ -187,8 +187,8 @@ Example response:
## Instance information ## Instance information
This get's some generic information about the instance. This is used This gets some generic information about the instance. This is used
by Geo nodes to get information about eachother by Geo nodes to get information about each other
```plaintext ```plaintext
GET /internal/check GET /internal/check
......
...@@ -435,7 +435,7 @@ We can consider the following types of storages: ...@@ -435,7 +435,7 @@ We can consider the following types of storages:
### Temporary storage ### Temporary storage
The storage on production nodes is really sparse. The application should be built 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` 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 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 jobs being run. If your job requires to use more than `100MB` of that space
......
...@@ -255,7 +255,7 @@ discouraged, and alternative approaches to processing the work should be ...@@ -255,7 +255,7 @@ discouraged, and alternative approaches to processing the work should be
considered. considered.
If a worker needs large amounts of both memory and CPU time, it should 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. memory-bound workers.
## Declaring a Job as CPU-bound ## Declaring a Job as CPU-bound
......
...@@ -210,7 +210,7 @@ secure note named `gitlab-{ce,ee} Review App's root password`. ...@@ -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) 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. 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) 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. aids in identifying load spikes on the cluster, and if nodes are problematic or the entire cluster is trending towards unhealthy.
......
...@@ -631,7 +631,7 @@ Here are some common pitfalls and how to overcome them: ...@@ -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" 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). 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 ### Reverting to basic search
......
...@@ -23,7 +23,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create ...@@ -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`. - **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. - **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.
![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png) ![Salesforce OAuth App Details](img/salesforce_oauth_app_details.png)
1. Click **Save**. 1. Click **Save**.
......
...@@ -103,7 +103,7 @@ The following assumes you already have Vault installed and running. ...@@ -103,7 +103,7 @@ The following assumes you already have Vault installed and running.
vault login -method=oidc port=8250 role=demo 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. 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`. 1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
......
...@@ -238,7 +238,7 @@ $ kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-a ...@@ -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 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 searching for vulnerabilities on our system. Detecting scanners is useful, because we
can learn if someone is trying to exploit our system. can learn if someone is trying to exploit our system.
......
...@@ -22,9 +22,9 @@ please submit a merge request to add an upcoming class, assign to ...@@ -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. To allow people to contribute all content should be in Git.
1. The content can go in a subdirectory under `/doc/university/`. 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) 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. 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 be public, if needed they can be unlisted but if so they should be linked from
this page. this page.
1. Please create a merge request and assign to [Erica](https://gitlab.com/Erica). 1. Please create a merge request and assign to [Erica](https://gitlab.com/Erica).
...@@ -447,7 +447,7 @@ instead of the usual three. ...@@ -447,7 +447,7 @@ instead of the usual three.
![A comment editor with a suggestion with a fenced code block](img/suggestion_code_block_editor_v12_8.png) ![A comment editor with a suggestion with a fenced code block](img/suggestion_code_block_editor_v12_8.png)
![Ouput of a comment with a suggestion with a fenced code block](img/suggestion_code_block_output_v12_8.png) ![Output of a comment with a suggestion with a fenced code block](img/suggestion_code_block_output_v12_8.png)
### Configure the commit message for applied Suggestions ### Configure the commit message for applied Suggestions
......
...@@ -368,7 +368,7 @@ variables. ...@@ -368,7 +368,7 @@ variables.
To set these: To set these:
1. Navigate to the project's **{settings}** **Settings > CI / CD**. 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`. `AWS_SECRET_ACCESS_KEY`.
1. Mask the credentials so they do not show in logs using the **Masked** toggle. 1. Mask the credentials so they do not show in logs using the **Masked** toggle.
......
...@@ -61,7 +61,7 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot ...@@ -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 | | Assignee Username | Username of the author, with the `@` symbol omitted |
| Confidential | `Yes` or `No` | | Confidential | `Yes` or `No` |
| Locked | `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` | | Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
| Updated 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 | | Milestone | Title of the issue milestone |
......
...@@ -175,7 +175,7 @@ For example, `workflow::backend::review` and `workflow::backend::development` ar ...@@ -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 scoped labels, but they **can't** exist on the same issue at the same time, as they
both share the same scope, `workflow::backend`. 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 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`. both have different scopes, `workflow::frontend` and `workflow::backend`.
......
...@@ -22,7 +22,7 @@ You can specify one or more coverage reports to collect, including wildcard path ...@@ -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 GitLab will then take the coverage information in all the files and combine it
together. 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 [Cobertura XML](https://cobertura.github.io/cobertura/) report to
[`artifacts:reports:cobertura`](../../../ci/yaml/README.md#artifactsreportscobertura). [`artifacts:reports:cobertura`](../../../ci/yaml/README.md#artifactsreportscobertura).
This format was originally developed for Java, but most coverage analysis frameworks This format was originally developed for Java, but most coverage analysis frameworks
......
...@@ -46,11 +46,8 @@ Single file editing is based on the [Ace Editor](https://ace.c9.io). ...@@ -46,11 +46,8 @@ Single file editing is based on the [Ace Editor](https://ace.c9.io).
## Commit changes ## 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. > - [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), > - From [GitLab 12.7 onward](https://gitlab.com/gitlab-org/gitlab/issues/33441), files were automatically staged.
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.
> - 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.
After making your changes, click the **Commit** button on the bottom-left to After making your changes, click the **Commit** button on the bottom-left to
review the list of changed files. review the list of changed files.
......
...@@ -5,6 +5,9 @@ module Gitlab ...@@ -5,6 +5,9 @@ module Gitlab
module DuplicateJobs module DuplicateJobs
class Client class Client
def call(worker_class, job, queue, _redis_pool, &block) def call(worker_class, job, queue, _redis_pool, &block)
# We don't try to deduplicate jobs that are scheduled in the future
return yield if job['at']
DuplicateJob.new(job, queue).schedule(&block) DuplicateJob.new(job, queue).schedule(&block)
end end
end end
......
...@@ -30,5 +30,15 @@ describe Gitlab::SidekiqMiddleware::DuplicateJobs::Client, :clean_gitlab_redis_q ...@@ -30,5 +30,15 @@ describe Gitlab::SidekiqMiddleware::DuplicateJobs::Client, :clean_gitlab_redis_q
expect(job2['duplicate-of']).to be_nil expect(job2['duplicate-of']).to be_nil
expect(job3['duplicate-of']).to eq(job1['jid']) expect(job3['duplicate-of']).to eq(job1['jid'])
end end
it "does not mark a job that's scheduled in the future as a duplicate" do
TestDeduplicationWorker.perform_async('args1')
TestDeduplicationWorker.perform_at(1.day.from_now, 'args1')
TestDeduplicationWorker.perform_in(3.hours, 'args1')
duplicates = TestDeduplicationWorker.jobs.map { |job| job['duplicate-of'] }
expect(duplicates).to all(be_nil)
end
end end
end end
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