Commit dddde902 authored by 🤖 GitLab Bot 🤖's avatar 🤖 GitLab Bot 🤖

Add latest changes from gitlab-org/[email protected]

parent 101c30f4
Pipeline #129817830 passed with stages
in 65 minutes and 51 seconds
......@@ -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`:
......
......@@ -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
......
......@@ -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)
......
......@@ -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.
......
......@@ -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 |
......@@ -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 |
......
......@@ -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
......
......@@ -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.
......
......@@ -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:
![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
[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:
![Merge request page](img/merge_request.png)
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
......
......@@ -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.
![Merge request pipeline as the head pipeline](img/merged_result_pipeline_v12_3.png)
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
......
......@@ -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.
......
......@@ -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
......
......@@ -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
......
......@@ -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)
......
......@@ -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
......
......@@ -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
......
......@@ -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>
......
......@@ -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
......
......@@ -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
......
# 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).
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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.
......
......@@ -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
......
......@@ -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.
![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png)
![Salesforce OAuth App Details](img/salesforce_oauth_app_details.png)
1. Click **Save**.
......
......@@ -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`.
......
......@@ -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.
......
......@@ -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).
......@@ -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)
![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
......
......@@ -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.
......
......@@ -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 |
......
......@@ -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`.
......
......@@ -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
......
......@@ -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.
......
......@@ -5,6 +5,9 @@ module Gitlab
module DuplicateJobs
class Client
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)
end
end
......
......@@ -30,5 +30,15 @@ describe Gitlab::SidekiqMiddleware::DuplicateJobs::Client, :clean_gitlab_redis_q
expect(job2['duplicate-of']).to be_nil
expect(job3['duplicate-of']).to eq(job1['jid'])
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
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