kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2020-11-10 03:09:04 +00:00
parent 1b1d9cdc17
commit 311212ced6
38 changed files with 561 additions and 541 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
app/assets/javascripts/behaviors/details_behavior.js
View file

@ -1,28 +0,0 @@
import $ from 'jquery';
$(() => {
$('body').on('click', '.js-details-target', function target() {
$(this)
.closest('.js-details-container')
.toggleClass('open');
});
// Show details content. Hides link after click.
//
// %div
// %a.js-details-expand
// %div.js-details-content
//
$('body').on('click', '.js-details-expand', function expand(e) {
e.preventDefault();
$(this)
.next('.js-details-content')
.removeClass('hide');
$(this).hide();
const truncatedItem = $(this).siblings('.js-details-short');
if (truncatedItem.length) {
truncatedItem.addClass('hide');
}
});
});

1
app/assets/javascripts/behaviors/index.js
View file

@ -4,7 +4,6 @@ import './bind_in_out';
import './markdown/render_gfm';
import initCopyAsGFM from './markdown/copy_as_gfm';
import initCopyToClipboard from './copy_to_clipboard';
import './details_behavior';
import installGlEmojiElement from './gl_emoji';
import './quick_submit';
import './requires_input';

3
app/assets/javascripts/projects/commit_box/info/index.js
View file

@ -1,4 +1,5 @@
import { loadBranches } from './load_branches';
import { initDetailsButton } from './init_details_button';
import { fetchCommitMergeRequests } from '~/commit_merge_requests';
import MiniPipelineGraph from '~/mini_pipeline_graph_dropdown';
@ -15,4 +16,6 @@ export const initCommitBoxInfo = (containerSelector = '.js-commit-box-info') =>
new MiniPipelineGraph({
container: '.js-commit-pipeline-graph',
}).bindEvents();
initDetailsButton();
};

11
app/assets/javascripts/projects/commit_box/info/init_details_button.js Normal file
View file

@ -0,0 +1,11 @@
import $ from 'jquery';
export const initDetailsButton = () => {
$('body').on('click', '.js-details-expand', function expand(e) {
e.preventDefault();
$(this)
.next('.js-details-content')
.removeClass('hide');
$(this).hide();
});
};

25
app/assets/stylesheets/behaviors.scss
View file

@ -1,28 +1,3 @@
// Details
//--------
.js-details-container {
.content {
display: none;
&.hide { display: block; }
}
&.open .content {
display: block;
&.hide { display: none; }
}
}
// Toggle between two states.
.js-toggler-container {
.turn-on { display: block; }
.turn-off { display: none; }
&.on {
.turn-on { display: none; }
.turn-off { display: block; }
}
}
// Hide element if Vue is still working on rendering it fully.
[v-cloak='true'] {
display: none !important;

17
app/assets/stylesheets/pages/commits.scss
View file

@ -14,12 +14,6 @@
@extend %commit-description-base;
}
.js-details-expand {
&:hover {
text-decoration: none;
}
}
.commit-box {
border-top: 1px solid $border-color;
padding: $gl-padding 0;
@ -30,17 +24,6 @@
}
}
.commit-hash-full {
@include media-breakpoint-down(sm) {
width: 80px;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
display: inline-block;
vertical-align: bottom;
}
}
.pipeline-info {
.status-icon-container {
display: inline-block;

1
app/controllers/registrations/welcome_controller.rb
View file

@ -51,7 +51,6 @@ module Registrations
def requires_confirmation?(user)
return false if user.confirmed?
return false if Feature.enabled?(:soft_email_confirmation)
return false if experiment_enabled?(:signup_flow)
true
end

6
app/graphql/resolvers/ci/runner_setup_resolver.rb
View file

@ -27,7 +27,7 @@ module Resolvers
)
{
install_instructions: instructions.install_script,
install_instructions: instructions.install_script || other_install_instructions(platform),
register_instructions: instructions.register_command
}
ensure
@ -36,6 +36,10 @@ module Resolvers
private
def other_install_instructions(platform)
Gitlab::Ci::RunnerInstructions::OTHER_ENVIRONMENTS[platform.to_sym][:installation_instructions_url]
end
def target_param(args)
project_param(args[:project_id]) || group_param(args[:group_id]) || {}
end

2
app/graphql/types/ci/runner_setup_type.rb
View file

@ -8,7 +8,7 @@ module Types
field :install_instructions, GraphQL::STRING_TYPE, null: false,
description: 'Instructions for installing the runner on the specified architecture'
field :register_instructions, GraphQL::STRING_TYPE, null: false,
field :register_instructions, GraphQL::STRING_TYPE, null: true,
description: 'Instructions for registering the runner'
end
end

7
app/views/projects/pipelines/_info.html.haml
View file

@ -57,12 +57,7 @@
.well-segment.branch-info
.icon-container.commit-icon
= custom_icon("icon_commit")
= link_to commit.short_id, project_commit_path(@project, @pipeline.sha), class: "commit-sha js-details-short"
= link_to("#", class: "js-details-expand d-none d-md-inline") do
%span.text-expander
= sprite_icon('ellipsis_h', size: 12)
%span.js-details-content.hide
= link_to @pipeline.sha, project_commit_path(@project, @pipeline.sha), class: "commit-sha commit-hash-full"
= link_to commit.short_id, project_commit_path(@project, @pipeline.sha), class: "commit-sha"
= clipboard_button(text: @pipeline.sha, title: _("Copy commit SHA"))
.well-segment.related-merge-request-info

5
changelogs/unreleased/25145-remove-expand-sha-button-pipeline.yml Normal file
View file

@ -0,0 +1,5 @@
---
title: Remove unnecessary expand sha button in pipelines page
merge_request: 47012
author:
type: fixed

5
changelogs/unreleased/ak-fix-loading-file.yml Normal file
View file

@ -0,0 +1,5 @@
---
title: Fix relative path not found on production web server
merge_request: 47090
author:
type: fixed

5
changelogs/unreleased/mc-bug-fix-k8s-docker-runner-setup.yml Normal file
View file

@ -0,0 +1,5 @@
---
title: Make register_instructions optional for RunnerSetup.
merge_request: 47123
author:
type: fixed

2
doc/api/graphql/reference/gitlab_schema.graphql
View file

@ -18411,7 +18411,7 @@ type RunnerSetup {
"""
Instructions for registering the runner
"""
registerInstructions: String!
registerInstructions: String
}
"""

10
doc/api/graphql/reference/gitlab_schema.json
View file

@ -53211,13 +53211,9 @@
],
"type": {
"kind": "NON_NULL",
"name": null,
"ofType": {
"kind": "SCALAR",
"name": "String",
"ofType": null
}
"kind": "SCALAR",
"name": "String",
"ofType": null
},
"isDeprecated": false,
"deprecationReason": null

2
doc/api/graphql/reference/index.md
View file

@ -2617,7 +2617,7 @@ Autogenerated return type of RunDASTScan.
| Field | Type | Description |
| ----- | ---- | ----------- |
| `installInstructions` | String! | Instructions for installing the runner on the specified architecture |
| `registerInstructions` | String! | Instructions for registering the runner |
| `registerInstructions` | String | Instructions for registering the runner |
### SastCiConfiguration

2
doc/ci/environments/index.md
View file

@ -697,7 +697,7 @@ stop_review:
```
If you can't use [Pipelines for merge requests](../merge_request_pipelines/index.md),
setting the [`GIT_STRATEGY`](../yaml/README.md#git-strategy) to `none` is necessary in the
setting the [`GIT_STRATEGY`](../runners/README.md#git-strategy) to `none` is necessary in the
`stop_review` job so that the [runner](https://docs.gitlab.com/runner/) won't
try to check out the code after the branch is deleted.

2
doc/ci/git_submodules.md
View file

@ -78,7 +78,7 @@ correctly with your CI jobs:
GIT_SUBMODULE_STRATEGY: recursive
```
See the [`.gitlab-ci.yml` reference](yaml/README.md#git-submodule-strategy)
See the [GitLab Runner documentation](runners/README.md#git-submodule-strategy)
for more details about `GIT_SUBMODULE_STRATEGY`.
1. If you are using an older version of `gitlab-runner`, then use

14
doc/ci/large_repositories/index.md
View file

@ -78,7 +78,7 @@ done by GitLab, requiring you to do them.
> Introduced in GitLab Runner 11.10.
[`GIT_CLONE_PATH`](../yaml/README.md#custom-build-directories) allows you to
[`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) allows you to
control where you clone your sources. This can have implications if you
heavily use big repositories with fork workflow.
@ -90,7 +90,7 @@ In such cases, ideally you want to make the GitLab Runner executor be used only
for the given project and not shared across different projects to make this
process more efficient.
The [`GIT_CLONE_PATH`](../yaml/README.md#custom-build-directories) has to be
The [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) has to be
within the `$CI_BUILDS_DIR`. Currently, it is impossible to pick any path
from disk.
@ -98,12 +98,12 @@ from disk.
> Introduced in GitLab Runner 11.10.
[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags) allows you to control
[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) allows you to control
whether or not you require the `git clean` command to be executed for each CI
job. By default, GitLab ensures that you have your worktree on the given SHA,
and that your repository is clean.
[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags) is disabled when set
[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) is disabled when set
to `none`. On very big repositories, this might be desired because `git
clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
-e .build/` (for example) allows you to control and disable removal of some
@ -112,7 +112,7 @@ the incremental builds. This has the biggest effect if you re-use existing
machines and have an existing worktree that you can re-use for builds.
For exact parameters accepted by
[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags), see the documentation
for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
are dependent on Git version.
@ -120,14 +120,14 @@ are dependent on Git version.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
[`GIT_FETCH_EXTRA_FLAGS`](../yaml/README.md#git-fetch-extra-flags) allows you
[`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags) allows you
to modify `git fetch` behavior by passing extra flags.
For example, if your project contains a large number of tags that your CI jobs don't rely on,
you could add [`--no-tags`](https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---no-tags)
to the extra flags to make your fetches faster and more compact.
See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../yaml/README.md#git-fetch-extra-flags)
See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/README.md#git-fetch-extra-flags)
for more information.
## Fork-based workflow

14
doc/ci/pipelines/schedules.md
View file

@ -85,10 +85,10 @@ job:
### Advanced configuration
The pipelines won't be executed exactly on schedule because schedules are handled by
The pipelines are not executed exactly on schedule because schedules are handled by
Sidekiq, which runs according to its interval.
For example, only two pipelines will be created per day if:
For example, only two pipelines are created per day if:
- You set a schedule to create a pipeline every minute (`* * * * *`).
- The Sidekiq worker runs on 00:00 and 12:00 every day (`0 */12 * * *`).
@ -112,8 +112,8 @@ To trigger a pipeline schedule manually, click the "Play" button:
![Play Pipeline Schedule](img/pipeline_schedule_play.png)
This will schedule a background job to run the pipeline schedule. A flash
message will provide a link to the CI/CD Pipeline index page.
This schedules a background job to run the pipeline schedule. A flash
message provides a link to the CI/CD Pipeline index page.
NOTE: **Note:**
To help avoid abuse, users are rate limited to triggering a pipeline once per
@ -124,12 +124,12 @@ minute.
Pipelines are executed as a user, who owns a schedule. This influences what projects and other resources the pipeline has access to.
If a user does not own a pipeline, you can take ownership by clicking the **Take ownership** button.
The next time a pipeline is scheduled, your credentials will be used.
The next time a pipeline is scheduled, your credentials are used.
![Schedules list](img/pipeline_schedules_ownership.png)
If the owner of a pipeline schedule doesn't have the ability to create
pipelines on the target branch, the schedule will stop creating new
If the owner of a pipeline schedule does not have the ability to create
pipelines on the target branch, the schedule stops creating new
pipelines.
This can happen if, for example:

2
doc/ci/pipelines/settings.md
View file

@ -29,7 +29,7 @@ There are two options. Using:
- `git fetch`, which is faster as it re-uses the local working copy (falling
back to clone if it doesn't exist).
The default Git strategy can be overridden by the [GIT_STRATEGY variable](../yaml/README.md#git-strategy)
The default Git strategy can be overridden by the [GIT_STRATEGY variable](../runners/README.md#git-strategy)
in `.gitlab-ci.yml`.
## Git shallow clone

336
doc/ci/runners/README.md
View file

@ -457,6 +457,342 @@ Example 2:
1. A job that has no tags defined is executed and run.
1. A second job that has a `docker` tag defined is stuck.
## Configure runner behavior with variables
You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior
globally or for individual jobs:
- [`GIT_STRATEGY`](#git-strategy)
- [`GIT_SUBMODULE_STRATEGY`](#git-submodule-strategy)
- [`GIT_CHECKOUT`](#git-checkout)
- [`GIT_CLEAN_FLAGS`](#git-clean-flags)
- [`GIT_FETCH_EXTRA_FLAGS`](#git-fetch-extra-flags)
- [`GIT_DEPTH`](#shallow-cloning) (shallow cloning)
- [`GIT_CLONE_PATH`](#custom-build-directories) (custom build directories)
You can also use variables to configure how many times a runner
[attempts certain stages of job execution](#job-stages-attempts).
### Git strategy
> - Introduced in GitLab 8.9 as an experimental feature.
> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
You can set the `GIT_STRATEGY` used for getting recent application code, either
globally or per-job in the [`variables`](../yaml/README.md#variables) section. If left
unspecified, the default from the project settings is used.
There are three possible values: `clone`, `fetch`, and `none`.
`clone` is the slowest option. It clones the repository from scratch for every
job, ensuring that the local working copy is always pristine.
```yaml
variables:
GIT_STRATEGY: clone
```
`fetch` is faster as it re-uses the local working copy (falling back to `clone`
if it does not exist). `git clean` is used to undo any changes made by the last
job, and `git fetch` is used to retrieve commits made since the last job ran.
```yaml
variables:
GIT_STRATEGY: fetch
```
`none` also re-uses the local working copy. However, it skips all Git operations,
including GitLab Runner's pre-clone script, if present.
It's useful for jobs that operate exclusively on artifacts, like a deployment job.
Git repository data may be present, but it's likely out-of-date. You should only
rely on files brought into the local working copy from cache or artifacts.
```yaml
variables:
GIT_STRATEGY: none
```
NOTE: **Note:**
`GIT_STRATEGY` is not supported for
[Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html),
but may be in the future. See the [support Git strategy with Kubernetes executor feature proposal](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847)
for updates.
### Git submodule strategy
> Requires GitLab Runner v1.10+.
The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git
submodules are included when fetching the code before a build. You can set them
globally or per-job in the [`variables`](../yaml/README.md#variables) section.
There are three possible values: `none`, `normal`, and `recursive`:
- `none` means that submodules are not included when fetching the project
code. This is the default, which matches the pre-v1.10 behavior.
- `normal` means that only the top-level submodules are included. It's
equivalent to:
```shell
git submodule sync
git submodule update --init
```
- `recursive` means that all submodules (including submodules of submodules)
are included. This feature needs Git v1.8.1 and later. When using a
GitLab Runner with an executor not based on Docker, make sure the Git version
meets that requirement. It's equivalent to:
```shell
git submodule sync --recursive
git submodule update --init --recursive
```
For this feature to work correctly, the submodules must be configured
(in `.gitmodules`) with either:
- the HTTP(S) URL of a publicly-accessible repository, or
- a relative path to another repository on the same GitLab server. See the
[Git submodules](../git_submodules.md) documentation.
### Git checkout
> Introduced in GitLab Runner 9.3.
The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either
`clone` or `fetch` to specify whether a `git checkout` should be run. If not
specified, it defaults to true. You can set them globally or per-job in the
[`variables`](../yaml/README.md#variables) section.
If set to `false`, the runner:
- when doing `fetch` - updates the repository and leaves the working copy on
the current revision,
- when doing `clone` - clones the repository and leaves the working copy on the
default branch.
If `GIT_CHECKOUT` is set to `true`, both `clone` and `fetch` work the same way.
The runner checks out the working copy of a revision related
to the CI pipeline:
```yaml
variables:
GIT_STRATEGY: clone
GIT_CHECKOUT: "false"
script:
- git checkout -B master origin/master
- git merge $CI_COMMIT_SHA
```
### Git clean flags
> Introduced in GitLab Runner 11.10
The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
`git clean` after checking out the sources. You can set it globally or per-job in the
[`variables`](../yaml/README.md#variables) section.
`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
command.
`git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
If `GIT_CLEAN_FLAGS` is:
- Not specified, `git clean` flags default to `-ffdx`.
- Given the value `none`, `git clean` is not executed.
For example:
```yaml
variables:
GIT_CLEAN_FLAGS: -ffdx -e cache/
script:
- ls -al cache/
```
### Git fetch extra flags
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of
`git fetch`. You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
`GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified.
The default flags are:
- [GIT_DEPTH](#shallow-cloning).
- The list of [refspecs](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec).
- A remote called `origin`.
If `GIT_FETCH_EXTRA_FLAGS` is:
- Not specified, `git fetch` flags default to `--prune --quiet` along with the default flags.
- Given the value `none`, `git fetch` is executed only with the default flags.
For example, the default flags are `--prune --quiet`, so you can make `git fetch` more verbose by overriding this with just `--prune`:
```yaml
variables:
GIT_FETCH_EXTRA_FLAGS: --prune
script:
- ls -al cache/
```
The configuration above results in `git fetch` being called this way:
```shell
git fetch origin $REFSPECS --depth 50 --prune
```
Where `$REFSPECS` is a value provided to the runner internally by GitLab.
### Shallow cloning
> Introduced in GitLab 8.9 as an experimental feature.
You can specify the depth of fetching and cloning using `GIT_DEPTH`.
`GIT_DEPTH` does a shallow clone of the repository and can significantly speed up cloning.
It can be helpful for repositories with a large number of commits or old, large binaries. The value is
passed to `git fetch` and `git clone`.
In GitLab 12.0 and later, newly-created projects automatically have a
[default `git depth` value of `50`](../pipelines/settings.md#git-shallow-clone).
If you use a depth of `1` and have a queue of jobs or retry
jobs, jobs may fail.
Git fetching and cloning is based on a ref, such as a branch name, so runners
can't clone a specific commit SHA. If multiple jobs are in the queue, or
you're retrying an old job, the commit to be tested must be within the
Git history that is cloned. Setting too small a value for `GIT_DEPTH` can make
it impossible to run these old commits and `unresolved reference` is displayed in
job logs. You should then reconsider changing `GIT_DEPTH` to a higher value.
Jobs that rely on `git describe` may not work correctly when `GIT_DEPTH` is
set since only part of the Git history is present.
To fetch or clone only the last 3 commits:
```yaml
variables:
GIT_DEPTH: "3"
```
You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
### Custom build directories
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2211) in GitLab Runner 11.10.
By default, GitLab Runner clones the repository in a unique subpath of the
`$CI_BUILDS_DIR` directory. However, your project might require the code in a
specific directory (Go projects, for example). In that case, you can specify
the `GIT_CLONE_PATH` variable to tell the runner the directory to clone the
repository in:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/project-name
test:
script:
- pwd
```
The `GIT_CLONE_PATH` has to always be within `$CI_BUILDS_DIR`. The directory set in `$CI_BUILDS_DIR`
is dependent on executor and configuration of [runners.builds_dir](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
setting.
This can only be used when `custom_build_dir` is enabled in the
[runner's configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscustom_build_dir-section).
This is the default configuration for the `docker` and `kubernetes` executors.
#### Handling concurrency
An executor that uses a concurrency greater than `1` might lead
to failures. Multiple jobs might be working on the same directory if the `builds_dir`
is shared between jobs.
The runner does not try to prevent this situation. It's up to the administrator
and developers to comply with the requirements of runner configuration.
To avoid this scenario, you can use a unique path within `$CI_BUILDS_DIR`, because runner
exposes two additional variables that provide a unique `ID` of concurrency:
- `$CI_CONCURRENT_ID`: Unique ID for all jobs running within the given executor.
- `$CI_CONCURRENT_PROJECT_ID`: Unique ID for all jobs running within the given executor and project.
The most stable configuration that should work well in any scenario and on any executor
is to use `$CI_CONCURRENT_ID` in the `GIT_CLONE_PATH`. For example:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-name
test:
script:
- pwd
```
The `$CI_CONCURRENT_PROJECT_ID` should be used in conjunction with `$CI_PROJECT_PATH`
as the `$CI_PROJECT_PATH` provides a path of a repository. That is, `group/subgroup/project`. For example:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATH
test:
script:
- pwd
```
#### Nested paths
The value of `GIT_CLONE_PATH` is expanded once and nesting variables
within is not supported.
For example, you define both the variables below in your
`.gitlab-ci.yml` file:
```yaml
variables:
GOPATH: $CI_BUILDS_DIR/go
GIT_CLONE_PATH: $GOPATH/src/namespace/project
```
The value of `GIT_CLONE_PATH` is expanded once into
`$CI_BUILDS_DIR/go/src/namespace/project`, and results in failure
because `$CI_BUILDS_DIR` is not expanded.
### Job stages attempts
> Introduced in GitLab, it requires GitLab Runner v1.9+.
You can set the number of attempts that the running job tries to execute
the following stages:
| Variable | Description |
|---------------------------------|--------------------------------------------------------|
| `ARTIFACT_DOWNLOAD_ATTEMPTS` | Number of attempts to download artifacts running a job |
| `EXECUTOR_JOB_SECTION_ATTEMPTS` | [In GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) and later, the number of attempts to run a section in a job after a [`No Such Container`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) error ([Docker executor](https://docs.gitlab.com/runner/executors/docker.html) only). |
| `GET_SOURCES_ATTEMPTS` | Number of attempts to fetch sources running a job |
| `RESTORE_CACHE_ATTEMPTS` | Number of attempts to restore the cache running a job |
The default is one single attempt.
Example:
```yaml
variables:
GET_SOURCES_ATTEMPTS: 3
```
You can set them globally or per-job in the [`variables`](../yaml/README.md#variables) section.
## System calls not available on GitLab.com shared runners
GitLab.com shared runners run on CoreOS. This means that you cannot use some system calls, like `getlogin`, from the C standard library.

413
doc/ci/yaml/README.md
View file

@ -2800,6 +2800,32 @@ URI-encoded `%2F`. A value made only of dots (`.`, `%2E`) is also forbidden.
You can specify a [fallback cache key](#fallback-cache-key) to use if the specified `cache:key` is not found.
#### Fallback cache key
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) in GitLab Runner 13.4.
You can use the `$CI_COMMIT_REF_SLUG` [variable](#variables) to specify your [`cache:key`](#cachekey).
For example, if your `$CI_COMMIT_REF_SLUG` is `test` you can set a job
to download cache that's tagged with `test`.
If a cache with this tag is not found, you can use `CACHE_FALLBACK_KEY` to
specify a cache to use when none exists.
For example:
```yaml
variables:
CACHE_FALLBACK_KEY: fallback-key
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- binaries/
```
In this example, if the `$CI_COMMIT_REF_SLUG` is not found, the job uses the key defined
by the `CACHE_FALLBACK_KEY` variable.
##### `cache:key:files`
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) in GitLab v12.5.
@ -3483,7 +3509,7 @@ Possible values for `when` are:
- `scheduler_failure`: Retry if the scheduler failed to assign the job to a runner.
- `data_integrity_failure`: Retry if there was a structural integrity problem detected.
You can specify the number of [retry attempts for certain stages of job execution](#job-stages-attempts) using variables.
You can specify the number of [retry attempts for certain stages of job execution](../runners/README.md#job-stages-attempts) using variables.
### `timeout`
@ -4145,8 +4171,8 @@ Read more on [GitLab Pages user documentation](../../user/project/pages/index.md
> Introduced in GitLab Runner v0.5.0.
Variables are configurable values that are passed to jobs. They can be set
globally and per-job.
[CI/CD variables](../variables/README.md) are configurable values that are passed to jobs.
They can be set globally and per-job.
There are two types of variables.
@ -4163,372 +4189,49 @@ Variables are meant for non-sensitive project configuration, for example:
```yaml
variables:
DATABASE_URL: "postgres://postgres@postgres/my_database"
DEPLOY_SITE: "https://example.com/"
deploy_job:
stage: deploy
script:
- deploy-script --url $DEPLOY_SITE --path "/"
deploy_review_job:
stage: deploy
variables:
REVIEW_PATH: "/review"
script:
- deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
```
You can use integers and strings for the variable's name and value.
You cannot use floats.
You can use only integers and strings for the variable's name and value.
If you define a variable at the top level of the `gitlab-ci.yml` file, it is global,
meaning it applies to all jobs.
If you define a variable within a job, it's available to that job only.
meaning it applies to all jobs. If you define a variable within a job, it's available
to that job only.
If a variable of the same name is defined globally and for a specific job, the
[job-specific variable is used](../variables/README.md#priority-of-environment-variables).
All YAML-defined variables are also set to any linked
[service containers](../docker/using_docker_images.md#what-is-a-service).
[Docker service containers](../docker/using_docker_images.md#what-is-a-service).
[YAML anchors for variables](#yaml-anchors-for-variables) are available.
You can use [YAML anchors for variables](#yaml-anchors-for-variables).
Learn more about [variables and their priority](../variables/README.md).
### Configure runner behavior with variables
### Git strategy
You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior:
> - Introduced in GitLab 8.9 as an experimental feature.
> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
- [`GIT_STRATEGY`](../runners/README.md#git-strategy)
- [`GIT_SUBMODULE_STRATEGY`](../runners/README.md#git-submodule-strategy)
- [`GIT_CHECKOUT`](../runners/README.md#git-checkout)
- [`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags)
- [`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags)
- [`GIT_DEPTH`](../runners/README.md#shallow-cloning) (shallow cloning)
- [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) (custom build directories)
You can set the `GIT_STRATEGY` used for getting recent application code, either
globally or per-job in the [`variables`](#variables) section. If left
unspecified, the default from the project settings is used.
There are three possible values: `clone`, `fetch`, and `none`.
`clone` is the slowest option. It clones the repository from scratch for every
job, ensuring that the local working copy is always pristine.
```yaml
variables:
GIT_STRATEGY: clone
```
`fetch` is faster as it re-uses the local working copy (falling back to `clone`
if it does not exist). `git clean` is used to undo any changes made by the last
job, and `git fetch` is used to retrieve commits made since the last job ran.
```yaml
variables:
GIT_STRATEGY: fetch
```
`none` also re-uses the local working copy. However, it skips all Git operations,
including GitLab Runner's pre-clone script, if present.
It's useful for jobs that operate exclusively on artifacts, like a deployment job.
Git repository data may be present, but it's likely out-of-date. You should only
rely on files brought into the local working copy from cache or artifacts.
```yaml
variables:
GIT_STRATEGY: none
```
NOTE: **Note:**
`GIT_STRATEGY` is not supported for
[Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html),
but may be in the future. See the [support Git strategy with Kubernetes executor feature proposal](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847)
for updates.
### Git submodule strategy
> Requires GitLab Runner v1.10+.
The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git
submodules are included when fetching the code before a build. You can set them
globally or per-job in the [`variables`](#variables) section.
There are three possible values: `none`, `normal`, and `recursive`:
- `none` means that submodules are not included when fetching the project
code. This is the default, which matches the pre-v1.10 behavior.
- `normal` means that only the top-level submodules are included. It's
equivalent to:
```shell
git submodule sync
git submodule update --init
```
- `recursive` means that all submodules (including submodules of submodules)
are included. This feature needs Git v1.8.1 and later. When using a
GitLab Runner with an executor not based on Docker, make sure the Git version
meets that requirement. It's equivalent to:
```shell
git submodule sync --recursive
git submodule update --init --recursive
```
For this feature to work correctly, the submodules must be configured
(in `.gitmodules`) with either:
- the HTTP(S) URL of a publicly-accessible repository, or
- a relative path to another repository on the same GitLab server. See the
[Git submodules](../git_submodules.md) documentation.
### Git checkout
> Introduced in GitLab Runner 9.3.
The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either
`clone` or `fetch` to specify whether a `git checkout` should be run. If not
specified, it defaults to true. You can set them globally or per-job in the
[`variables`](#variables) section.
If set to `false`, the runner:
- when doing `fetch` - updates the repository and leaves the working copy on
the current revision,
- when doing `clone` - clones the repository and leaves the working copy on the
default branch.
If `GIT_CHECKOUT` is set to `true`, both `clone` and `fetch` work the same way.
The runner checks out the working copy of a revision related
to the CI pipeline:
```yaml
variables:
GIT_STRATEGY: clone
GIT_CHECKOUT: "false"
script:
- git checkout -B master origin/master
- git merge $CI_COMMIT_SHA
```
### Git clean flags
> Introduced in GitLab Runner 11.10
The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
`git clean` after checking out the sources. You can set it globally or per-job in the
[`variables`](#variables) section.
`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
command.
`git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
If `GIT_CLEAN_FLAGS` is:
- Not specified, `git clean` flags default to `-ffdx`.
- Given the value `none`, `git clean` is not executed.
For example:
```yaml
variables:
GIT_CLEAN_FLAGS: -ffdx -e cache/
script:
- ls -al cache/
```
### Git fetch extra flags
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of
`git fetch`. You can set it globally or per-job in the [`variables`](#variables) section.
`GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified.
The default flags are:
- [GIT_DEPTH](#shallow-cloning).
- The list of [refspecs](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec).
- A remote called `origin`.
If `GIT_FETCH_EXTRA_FLAGS` is:
- Not specified, `git fetch` flags default to `--prune --quiet` along with the default flags.
- Given the value `none`, `git fetch` is executed only with the default flags.
For example, the default flags are `--prune --quiet`, so you can make `git fetch` more verbose by overriding this with just `--prune`:
```yaml
variables:
GIT_FETCH_EXTRA_FLAGS: --prune
script:
- ls -al cache/
```
The configuration above results in `git fetch` being called this way:
```shell
git fetch origin $REFSPECS --depth 50 --prune
```
Where `$REFSPECS` is a value provided to the runner internally by GitLab.
### Job stages attempts
> Introduced in GitLab, it requires GitLab Runner v1.9+.
You can set the number of attempts that the running job tries to execute
the following stages:
| Variable | Description |
|-----------------------------------|--------------------------------------------------------|
| **ARTIFACT_DOWNLOAD_ATTEMPTS** | Number of attempts to download artifacts running a job |
| **EXECUTOR_JOB_SECTION_ATTEMPTS** | [In GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) and later, the number of attempts to run a section in a job after a [`No Such Container`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) error ([Docker executor](https://docs.gitlab.com/runner/executors/docker.html) only). |
| **GET_SOURCES_ATTEMPTS** | Number of attempts to fetch sources running a job |
| **RESTORE_CACHE_ATTEMPTS** | Number of attempts to restore the cache running a job |
The default is one single attempt.
Example:
```yaml
variables:
GET_SOURCES_ATTEMPTS: 3
```
You can set them globally or per-job in the [`variables`](#variables) section.
### Fallback cache key
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) in GitLab Runner 13.4.
You can use the `$CI_COMMIT_REF_SLUG` variable to specify your [`cache:key`](#cachekey).
For example, if your `$CI_COMMIT_REF_SLUG` is `test` you can set a job
to download cache that's tagged with `test`.
If a cache with this tag is not found, you can use `CACHE_FALLBACK_KEY` to
specify a cache to use when none exists.
For example:
```yaml
variables:
CACHE_FALLBACK_KEY: fallback-key
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- binaries/
```
In this example, if the `$CI_COMMIT_REF_SLUG` is not found, the job uses the key defined
by the `CACHE_FALLBACK_KEY` variable.
### Shallow cloning
> Introduced in GitLab 8.9 as an experimental feature.
You can specify the depth of fetching and cloning using `GIT_DEPTH`.
`GIT_DEPTH` does a shallow clone of the repository and can significantly speed up cloning.
It can be helpful for repositories with a large number of commits or old, large binaries. The value is
passed to `git fetch` and `git clone`.
In GitLab 12.0 and later, newly-created projects automatically have a
[default `git depth` value of `50`](../pipelines/settings.md#git-shallow-clone).
If you use a depth of `1` and have a queue of jobs or retry
jobs, jobs may fail.
Git fetching and cloning is based on a ref, such as a branch name, so runners
can't clone a specific commit SHA. If multiple jobs are in the queue, or
you're retrying an old job, the commit to be tested must be within the
Git history that is cloned. Setting too small a value for `GIT_DEPTH` can make
it impossible to run these old commits and `unresolved reference` is displayed in
job logs. You should then reconsider changing `GIT_DEPTH` to a higher value.
Jobs that rely on `git describe` may not work correctly when `GIT_DEPTH` is
set since only part of the Git history is present.
To fetch or clone only the last 3 commits:
```yaml
variables:
GIT_DEPTH: "3"
```
You can set it globally or per-job in the [`variables`](#variables) section.
### Custom build directories
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2211) in GitLab Runner 11.10.
By default, GitLab Runner clones the repository in a unique subpath of the
`$CI_BUILDS_DIR` directory. However, your project might require the code in a
specific directory (Go projects, for example). In that case, you can specify
the `GIT_CLONE_PATH` variable to tell the runner the directory to clone the
repository in:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/project-name
test:
script:
- pwd
```
The `GIT_CLONE_PATH` has to always be within `$CI_BUILDS_DIR`. The directory set in `$CI_BUILDS_DIR`
is dependent on executor and configuration of [runners.builds_dir](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
setting.
This can only be used when `custom_build_dir` is enabled in the
[runner's configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscustom_build_dir-section).
This is the default configuration for the `docker` and `kubernetes` executors.
#### Handling concurrency
An executor that uses a concurrency greater than `1` might lead
to failures. Multiple jobs might be working on the same directory if the `builds_dir`
is shared between jobs.
The runner does not try to prevent this situation. It's up to the administrator
and developers to comply with the requirements of runner configuration.
To avoid this scenario, you can use a unique path within `$CI_BUILDS_DIR`, because runner
exposes two additional variables that provide a unique `ID` of concurrency:
- `$CI_CONCURRENT_ID`: Unique ID for all jobs running within the given executor.
- `$CI_CONCURRENT_PROJECT_ID`: Unique ID for all jobs running within the given executor and project.
The most stable configuration that should work well in any scenario and on any executor
is to use `$CI_CONCURRENT_ID` in the `GIT_CLONE_PATH`. For example:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-name
test:
script:
- pwd
```
The `$CI_CONCURRENT_PROJECT_ID` should be used in conjunction with `$CI_PROJECT_PATH`
as the `$CI_PROJECT_PATH` provides a path of a repository. That is, `group/subgroup/project`. For example:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATH
test:
script:
- pwd
```
#### Nested paths
The value of `GIT_CLONE_PATH` is expanded once and nesting variables
within is not supported.
For example, you define both the variables below in your
`.gitlab-ci.yml` file:
```yaml
variables:
GOPATH: $CI_BUILDS_DIR/go
GIT_CLONE_PATH: $GOPATH/src/namespace/project
```
The value of `GIT_CLONE_PATH` is expanded once into
`$CI_BUILDS_DIR/go/src/namespace/project`, and results in failure
because `$CI_BUILDS_DIR` is not expanded.
You can also use variables to configure how many times a runner
[attempts certain stages of job execution](../runners/README.md#job-stages-attempts).
## Special YAML features

2
doc/user/application_security/container_scanning/index.md
View file

@ -437,7 +437,7 @@ automatically generates.
To enable remediation support, the scanning tool _must_ have access to the `Dockerfile` specified by
the [`DOCKERFILE_PATH`](#available-variables) environment variable. To ensure that the scanning tool
has access to this
file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/yaml/README.md#git-strategy) in
file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/README.md#git-strategy) in
your `.gitlab-ci.yml` file by following the instructions described in this document's
[overriding the container scanning template](#overriding-the-container-scanning-template) section.

2
doc/user/application_security/dast/index.md
View file

@ -603,7 +603,7 @@ variables:
### Cloning the project's repository
The DAST job does not require the project's repository to be present when running, so by default
[`GIT_STRATEGY`](../../../ci/yaml/README.md#git-strategy) is set to `none`.
[`GIT_STRATEGY`](../../../ci/runners/README.md#git-strategy) is set to `none`.
### Debugging DAST jobs

2
lib/gitlab/ci/runner_instructions.rb
View file

@ -106,7 +106,7 @@ module Gitlab
end
def get_file(path)
File.read(path)
File.read(Rails.root.join(path).to_s)
end
def registration_token

4
lib/gitlab/experimentation.rb
View file

@ -33,10 +33,6 @@ require 'zlib'
module Gitlab
module Experimentation
EXPERIMENTS = {
signup_flow: {
tracking_category: 'Growth::Acquisition::Experiment::SignUpFlow',
use_backwards_compatible_subject_index: true
},
onboarding_issues: {
tracking_category: 'Growth::Conversion::Experiment::OnboardingIssues',
use_backwards_compatible_subject_index: true

3
spec/frontend/deploy_freeze/components/deploy_freeze_modal_spec.js
View file

@ -4,6 +4,7 @@ import { GlButton, GlModal } from '@gitlab/ui';
import DeployFreezeModal from '~/deploy_freeze/components/deploy_freeze_modal.vue';
import TimezoneDropdown from '~/vue_shared/components/timezone_dropdown.vue';
import createStore from '~/deploy_freeze/store';
import { freezePeriodsFixture, timezoneDataFixture } from '../helpers';
const localVue = createLocalVue();
localVue.use(Vuex);
@ -11,8 +12,6 @@ localVue.use(Vuex);
describe('Deploy freeze modal', () => {
let wrapper;
let store;
const freezePeriodsFixture = getJSONFixture('/api/freeze-periods/freeze_periods.json');
const timezoneDataFixture = getJSONFixture('/api/freeze-periods/timezone_data.json');
beforeEach(() => {
store = createStore({

2
spec/frontend/deploy_freeze/components/deploy_freeze_settings_spec.js
View file

@ -4,6 +4,7 @@ import DeployFreezeSettings from '~/deploy_freeze/components/deploy_freeze_setti
import DeployFreezeTable from '~/deploy_freeze/components/deploy_freeze_table.vue';
import DeployFreezeModal from '~/deploy_freeze/components/deploy_freeze_modal.vue';
import createStore from '~/deploy_freeze/store';
import { timezoneDataFixture } from '../helpers';
const localVue = createLocalVue();
localVue.use(Vuex);
@ -11,7 +12,6 @@ localVue.use(Vuex);
describe('Deploy freeze settings', () => {
let wrapper;
let store;
const timezoneDataFixture = getJSONFixture('/api/freeze-periods/timezone_data.json');
beforeEach(() => {
store = createStore({

3
spec/frontend/deploy_freeze/components/deploy_freeze_table_spec.js
View file

@ -2,6 +2,7 @@ import Vuex from 'vuex';
import { createLocalVue, mount } from '@vue/test-utils';
import DeployFreezeTable from '~/deploy_freeze/components/deploy_freeze_table.vue';
import createStore from '~/deploy_freeze/store';
import { freezePeriodsFixture, timezoneDataFixture } from '../helpers';
const localVue = createLocalVue();
localVue.use(Vuex);
@ -9,7 +10,6 @@ localVue.use(Vuex);
describe('Deploy freeze table', () => {
let wrapper;
let store;
const timezoneDataFixture = getJSONFixture('/api/freeze-periods/timezone_data.json');
const createComponent = () => {
store = createStore({
@ -50,7 +50,6 @@ describe('Deploy freeze table', () => {
});
it('displays data', () => {
const freezePeriodsFixture = getJSONFixture('/api/freeze-periods/freeze_periods.json');
store.state.freezePeriods = freezePeriodsFixture;
return wrapper.vm.$nextTick(() => {

8
spec/frontend/deploy_freeze/components/timezone_dropdown_spec.js
View file

@ -1,9 +1,9 @@
import Vuex from 'vuex';
import { shallowMount, createLocalVue } from '@vue/test-utils';
import { GlDropdownItem, GlDropdown } from '@gitlab/ui';
import { secondsToHours } from '~/lib/utils/datetime_utility';
import TimezoneDropdown from '~/vue_shared/components/timezone_dropdown.vue';
import createStore from '~/deploy_freeze/store';
import { findTzByName, formatTz, timezoneDataFixture } from '../helpers';
const localVue = createLocalVue();
localVue.use(Vuex);
@ -11,12 +11,6 @@ localVue.use(Vuex);
describe('Deploy freeze timezone dropdown', () => {
let wrapper;
let store;
const timezoneDataFixture = getJSONFixture('/api/freeze-periods/timezone_data.json');
const findTzByName = (identifier = '') =>
timezoneDataFixture.find(({ name }) => name.toLowerCase() === identifier.toLowerCase());
const formatTz = ({ offset, name }) => `[UTC ${secondsToHours(offset)}] ${name}`;
const createComponent = (searchTerm, selectedTimezone) => {
store = createStore({

9
spec/frontend/deploy_freeze/helpers.js Normal file
View file

@ -0,0 +1,9 @@
import { secondsToHours } from '~/lib/utils/datetime_utility';
export const freezePeriodsFixture = getJSONFixture('/api/freeze-periods/freeze_periods.json');
export const timezoneDataFixture = getJSONFixture('/api/freeze-periods/timezone_data.json');
export const findTzByName = (identifier = '') =>
timezoneDataFixture.find(({ name }) => name.toLowerCase() === identifier.toLowerCase());
export const formatTz = ({ offset, name }) => `[UTC ${secondsToHours(offset)}] ${name}`;

3
spec/frontend/deploy_freeze/store/actions_spec.js
View file

@ -6,6 +6,7 @@ import { deprecatedCreateFlash as createFlash } from '~/flash';
import getInitialState from '~/deploy_freeze/store/state';
import * as actions from '~/deploy_freeze/store/actions';
import * as types from '~/deploy_freeze/store/mutation_types';
import { freezePeriodsFixture, timezoneDataFixture } from '../helpers';
jest.mock('~/api.js');
jest.mock('~/flash.js');
@ -13,8 +14,6 @@ jest.mock('~/flash.js');
describe('deploy freeze store actions', () => {
let mock;
let state;
const freezePeriodsFixture = getJSONFixture('/api/freeze-periods/freeze_periods.json');
const timezoneDataFixture = getJSONFixture('/api/freeze-periods/timezone_data.json');
beforeEach(() => {
mock = new MockAdapter(axios);

8
spec/frontend/deploy_freeze/store/mutations_spec.js
View file

@ -2,10 +2,10 @@ import state from '~/deploy_freeze/store/state';
import mutations from '~/deploy_freeze/store/mutations';
import * as types from '~/deploy_freeze/store/mutation_types';
import { convertObjectPropsToCamelCase } from '~/lib/utils/common_utils';
import { findTzByName, formatTz, freezePeriodsFixture, timezoneDataFixture } from '../helpers';
describe('Deploy freeze mutations', () => {
let stateCopy;
const timezoneDataFixture = getJSONFixture('/api/freeze-periods/timezone_data.json');
beforeEach(() => {
stateCopy = state({
@ -28,7 +28,6 @@ describe('Deploy freeze mutations', () => {
describe('RECEIVE_FREEZE_PERIODS_SUCCESS', () => {
it('should set freeze periods and format timezones from identifiers to names', () => {
const timezoneNames = ['Berlin', 'UTC', 'Eastern Time (US & Canada)'];
const freezePeriodsFixture = getJSONFixture('/api/freeze-periods/freeze_periods.json');
mutations[types.RECEIVE_FREEZE_PERIODS_SUCCESS](stateCopy, freezePeriodsFixture);
@ -43,9 +42,10 @@ describe('Deploy freeze mutations', () => {
describe('SET_SELECTED_TIMEZONE', () => {
it('should set the cron timezone', () => {
const selectedTz = findTzByName('Pacific Time (US & Canada)');
const timezone = {
formattedTimezone: '[UTC -7] Pacific Time (US & Canada)',
identifier: 'America/Los_Angeles',
formattedTimezone: formatTz(selectedTz),
identifier: selectedTz.identifier,
};
mutations[types.SET_SELECTED_TIMEZONE](stateCopy, timezone);

9
spec/frontend/fixtures/freeze_period.rb
View file

@ -17,6 +17,15 @@ RSpec.describe 'Freeze Periods (JavaScript fixtures)' do
remove_repository(project)
end
around do |example|
freeze_time do
# Mock time to sept 19 (intl. talk like a pirate day)
Timecop.travel(2020, 9, 19)
example.run
end
end
describe API::FreezePeriods, '(JavaScript fixtures)', type: :request do
include ApiHelpers

126
spec/graphql/resolvers/ci/runner_setup_resolver_spec.rb
View file

@ -8,77 +8,95 @@ RSpec.describe Resolvers::Ci::RunnerSetupResolver do
describe '#resolve' do
let(:user) { create(:user) }
subject(:resolve_subject) { resolve(described_class, ctx: { current_user: user }, args: { platform: 'linux', architecture: 'amd64' }.merge(target_param)) }
subject(:resolve_subject) { resolve(described_class, ctx: { current_user: user }, args: { platform: platform, architecture: 'amd64' }.merge(target_param)) }
context 'without target parameter' do
let(:target_param) { {} }
context 'when user is not admin' do
it 'returns access error' do
expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
end
end
context 'when user is admin' do
before do
user.update!(admin: true)
end
it 'returns install and register instructions' do
expect(resolve_subject.keys).to contain_exactly(:install_instructions, :register_instructions)
expect(resolve_subject.values).not_to include(nil)
end
end
end
context 'with project target parameter' do
context 'with container platforms' do
let(:platform) { 'docker' }
let(:project) { create(:project) }
let(:target_param) { { project_id: project.to_global_id } }
context 'when user has access to admin builds on project' do
before do
project.add_maintainer(user)
end
it 'returns install and register instructions' do
expect(resolve_subject.keys).to contain_exactly(:install_instructions, :register_instructions)
expect(resolve_subject.values).not_to include(nil)
end
it 'returns install instructions' do
expect(resolve_subject[:install_instructions]).not_to eq(nil)
end
context 'when user does not have access to admin builds on project' do
before do
project.add_developer(user)
end
it 'returns access error' do
expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
end
it 'does not return register instructions' do
expect(resolve_subject[:register_instructions]).to eq(nil)
end
end
context 'with group target parameter' do
let(:group) { create(:group) }
let(:target_param) { { group_id: group.to_global_id } }
context 'with regular platforms' do
let(:platform) { 'linux' }
context 'when user has access to admin builds on group' do
before do
group.add_owner(user)
context 'without target parameter' do
let(:target_param) { {} }
context 'when user is not admin' do
it 'returns access error' do
expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
end
end
it 'returns install and register instructions' do
expect(resolve_subject.keys).to contain_exactly(:install_instructions, :register_instructions)
expect(resolve_subject.values).not_to include(nil)
context 'when user is admin' do
before do
user.update!(admin: true)
end
it 'returns install and register instructions' do
expect(resolve_subject.keys).to contain_exactly(:install_instructions, :register_instructions)
expect(resolve_subject.values).not_to include(nil)
end
end
end
context 'when user does not have access to admin builds on group' do
before do
group.add_developer(user)
context 'with project target parameter' do
let(:project) { create(:project) }
let(:target_param) { { project_id: project.to_global_id } }
context 'when user has access to admin builds on project' do
before do
project.add_maintainer(user)
end
it 'returns install and register instructions' do
expect(resolve_subject.keys).to contain_exactly(:install_instructions, :register_instructions)
expect(resolve_subject.values).not_to include(nil)
end
end
it 'returns access error' do
expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
context 'when user does not have access to admin builds on project' do
before do
project.add_developer(user)
end
it 'returns access error' do
expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
end
end
end
context 'with group target parameter' do
let(:group) { create(:group) }
let(:target_param) { { group_id: group.to_global_id } }
context 'when user has access to admin builds on group' do
before do
group.add_owner(user)
end
it 'returns install and register instructions' do
expect(resolve_subject.keys).to contain_exactly(:install_instructions, :register_instructions)
expect(resolve_subject.values).not_to include(nil)
end
end
context 'when user does not have access to admin builds on group' do
before do
group.add_developer(user)
end
it 'returns access error' do
expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
end
end
end
end

7
spec/lib/gitlab/ci/runner_instructions_spec.rb
View file

@ -75,6 +75,13 @@ RSpec.describe Gitlab::Ci::RunnerInstructions do
with_them do
let(:params) { { os: os, arch: arch } }
around do |example|
# puma in production does not run from Rails.root, ensure file loading does not assume this
Dir.chdir(Rails.root.join('tmp').to_s) do
example.run
end
end
it 'returns string containing correct params' do
result = subject.install_script

1
spec/lib/gitlab/experimentation_spec.rb
View file

@ -7,7 +7,6 @@ require 'spec_helper'
RSpec.describe Gitlab::Experimentation::EXPERIMENTS do
it 'temporarily ensures we know what experiments exist for backwards compatibility' do
expected_experiment_keys = [
:signup_flow,
:onboarding_issues,
:ci_notification_dot,
:upgrade_link_in_user_menu_a,