diff options
38 files changed, 555 insertions, 535 deletions
diff --git a/app/assets/javascripts/behaviors/details_behavior.js b/app/assets/javascripts/behaviors/details_behavior.js deleted file mode 100644 index 9bdfc21c7e4..00000000000 --- a/app/assets/javascripts/behaviors/details_behavior.js +++ /dev/null @@ -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'); - } - }); -}); diff --git a/app/assets/javascripts/behaviors/index.js b/app/assets/javascripts/behaviors/index.js index 613309a1c5a..75659bbf685 100644 --- a/app/assets/javascripts/behaviors/index.js +++ b/app/assets/javascripts/behaviors/index.js @@ -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'; diff --git a/app/assets/javascripts/projects/commit_box/info/index.js b/app/assets/javascripts/projects/commit_box/info/index.js index 352ac39f3c4..254d178f013 100644 --- a/app/assets/javascripts/projects/commit_box/info/index.js +++ b/app/assets/javascripts/projects/commit_box/info/index.js @@ -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(); }; diff --git a/app/assets/javascripts/projects/commit_box/info/init_details_button.js b/app/assets/javascripts/projects/commit_box/info/init_details_button.js new file mode 100644 index 00000000000..032fbf5316a --- /dev/null +++ b/app/assets/javascripts/projects/commit_box/info/init_details_button.js @@ -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(); + }); +}; diff --git a/app/assets/stylesheets/behaviors.scss b/app/assets/stylesheets/behaviors.scss index 120a139ff3d..bcfa5bac5d5 100644 --- a/app/assets/stylesheets/behaviors.scss +++ b/app/assets/stylesheets/behaviors.scss @@ -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; diff --git a/app/assets/stylesheets/pages/commits.scss b/app/assets/stylesheets/pages/commits.scss index c55bfeb7b15..1ad77a52b1d 100644 --- a/app/assets/stylesheets/pages/commits.scss +++ b/app/assets/stylesheets/pages/commits.scss @@ -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; diff --git a/app/controllers/registrations/welcome_controller.rb b/app/controllers/registrations/welcome_controller.rb index a5340cf26b6..5b3f78a92ad 100644 --- a/app/controllers/registrations/welcome_controller.rb +++ b/app/controllers/registrations/welcome_controller.rb @@ -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 diff --git a/app/graphql/resolvers/ci/runner_setup_resolver.rb b/app/graphql/resolvers/ci/runner_setup_resolver.rb index 6665096d1a1..241cd57f74b 100644 --- a/app/graphql/resolvers/ci/runner_setup_resolver.rb +++ b/app/graphql/resolvers/ci/runner_setup_resolver.rb @@ -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 diff --git a/app/graphql/types/ci/runner_setup_type.rb b/app/graphql/types/ci/runner_setup_type.rb index 8bfc80f5dfe..66abcf65adf 100644 --- a/app/graphql/types/ci/runner_setup_type.rb +++ b/app/graphql/types/ci/runner_setup_type.rb @@ -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 diff --git a/app/views/projects/pipelines/_info.html.haml b/app/views/projects/pipelines/_info.html.haml index ae3435cc9a3..f77f22cc555 100644 --- a/app/views/projects/pipelines/_info.html.haml +++ b/app/views/projects/pipelines/_info.html.haml @@ -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 diff --git a/changelogs/unreleased/25145-remove-expand-sha-button-pipeline.yml b/changelogs/unreleased/25145-remove-expand-sha-button-pipeline.yml new file mode 100644 index 00000000000..d95d4916a1f --- /dev/null +++ b/changelogs/unreleased/25145-remove-expand-sha-button-pipeline.yml @@ -0,0 +1,5 @@ +--- +title: Remove unnecessary expand sha button in pipelines page +merge_request: 47012 +author: +type: fixed diff --git a/changelogs/unreleased/ak-fix-loading-file.yml b/changelogs/unreleased/ak-fix-loading-file.yml new file mode 100644 index 00000000000..16396855b37 --- /dev/null +++ b/changelogs/unreleased/ak-fix-loading-file.yml @@ -0,0 +1,5 @@ +--- +title: Fix relative path not found on production web server +merge_request: 47090 +author: +type: fixed diff --git a/changelogs/unreleased/mc-bug-fix-k8s-docker-runner-setup.yml b/changelogs/unreleased/mc-bug-fix-k8s-docker-runner-setup.yml new file mode 100644 index 00000000000..0cfd5f8b0de --- /dev/null +++ b/changelogs/unreleased/mc-bug-fix-k8s-docker-runner-setup.yml @@ -0,0 +1,5 @@ +--- +title: Make register_instructions optional for RunnerSetup. +merge_request: 47123 +author: +type: fixed diff --git a/doc/api/graphql/reference/gitlab_schema.graphql b/doc/api/graphql/reference/gitlab_schema.graphql index df136e9c8c0..78fa3956920 100644 --- a/doc/api/graphql/reference/gitlab_schema.graphql +++ b/doc/api/graphql/reference/gitlab_schema.graphql @@ -18411,7 +18411,7 @@ type RunnerSetup { """ Instructions for registering the runner """ - registerInstructions: String! + registerInstructions: String } """ diff --git a/doc/api/graphql/reference/gitlab_schema.json b/doc/api/graphql/reference/gitlab_schema.json index 375bdd036cc..e26a4b308cc 100644 --- a/doc/api/graphql/reference/gitlab_schema.json +++ b/doc/api/graphql/reference/gitlab_schema.json @@ -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 diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md index 1eeaab813f1..d8b31ceb09a 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -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 diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md index ea558a5f2f8..361b7217d17 100644 --- a/doc/ci/environments/index.md +++ b/doc/ci/environments/index.md @@ -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. diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md index 5bcfe8fa3f1..c28febd15d7 100644 --- a/doc/ci/git_submodules.md +++ b/doc/ci/git_submodules.md @@ -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 diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md index 0019eb5f40c..3464b981454 100644 --- a/doc/ci/large_repositories/index.md +++ b/doc/ci/large_repositories/index.md @@ -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 diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md index bcdb7c4c8b6..9df73957293 100644 --- a/doc/ci/pipelines/schedules.md +++ b/doc/ci/pipelines/schedules.md @@ -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:  -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.  -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: diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md index 6619f1b5f02..26e2a09fdef 100644 --- a/doc/ci/pipelines/settings.md +++ b/doc/ci/pipelines/settings.md @@ -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 diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md index f4d339c542d..b0117720b7e 100644 --- a/doc/ci/runners/README.md +++ b/doc/ci/runners/README.md @@ -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. diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 2e4049f91af..5c11e823c68 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -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). - -[YAML anchors for variables](#yaml-anchors-for-variables) are available. - -Learn more about [variables and their priority](../variables/README.md). - -### 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`](#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: +[Docker service containers](../docker/using_docker_images.md#what-is-a-service). -- [GIT_DEPTH](#shallow-cloning). -- The list of [refspecs](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec). -- A remote called `origin`. +You can use [YAML anchors for variables](#yaml-anchors-for-variables). -If `GIT_FETCH_EXTRA_FLAGS` is: +### Configure runner behavior with variables -- 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. +You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior: -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 -``` +- [`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) -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 diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index c6b9c574242..4e3eef8c5a8 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -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. diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index 4abf80be09a..2f1ed2faf90 100644 --- a/doc/user/application_security/dast/index.md +++ b/doc/user/application_security/dast/index.md @@ -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 diff --git a/lib/gitlab/ci/runner_instructions.rb b/lib/gitlab/ci/runner_instructions.rb index 2171637687f..dd0bfa768a8 100644 --- a/lib/gitlab/ci/runner_instructions.rb +++ b/lib/gitlab/ci/runner_instructions.rb @@ -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 diff --git a/lib/gitlab/experimentation.rb b/lib/gitlab/experimentation.rb index 6411c9f8353..fdb869eb4c2 100644 --- a/lib/gitlab/experimentation.rb +++ b/lib/gitlab/experimentation.rb @@ -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 diff --git a/spec/frontend/deploy_freeze/components/deploy_freeze_modal_spec.js b/spec/frontend/deploy_freeze/components/deploy_freeze_modal_spec.js index 9ecf6bf375b..9f28ddfd230 100644 --- a/spec/frontend/deploy_freeze/components/deploy_freeze_modal_spec.js +++ b/spec/frontend/deploy_freeze/components/deploy_freeze_modal_spec.js @@ -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({ diff --git a/spec/frontend/deploy_freeze/components/deploy_freeze_settings_spec.js b/spec/frontend/deploy_freeze/components/deploy_freeze_settings_spec.js index d40df7de7d1..c29a0c0ca73 100644 --- a/spec/frontend/deploy_freeze/components/deploy_freeze_settings_spec.js +++ b/spec/frontend/deploy_freeze/components/deploy_freeze_settings_spec.js @@ -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({ diff --git a/spec/frontend/deploy_freeze/components/deploy_freeze_table_spec.js b/spec/frontend/deploy_freeze/components/deploy_freeze_table_spec.js index 383ffa90b22..8480705b5e3 100644 --- a/spec/frontend/deploy_freeze/components/deploy_freeze_table_spec.js +++ b/spec/frontend/deploy_freeze/components/deploy_freeze_table_spec.js @@ -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(() => { diff --git a/spec/frontend/deploy_freeze/components/timezone_dropdown_spec.js b/spec/frontend/deploy_freeze/components/timezone_dropdown_spec.js index d1219627ca7..2aa977dfa5a 100644 --- a/spec/frontend/deploy_freeze/components/timezone_dropdown_spec.js +++ b/spec/frontend/deploy_freeze/components/timezone_dropdown_spec.js @@ -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({ diff --git a/spec/frontend/deploy_freeze/helpers.js b/spec/frontend/deploy_freeze/helpers.js new file mode 100644 index 00000000000..bfb84142662 --- /dev/null +++ b/spec/frontend/deploy_freeze/helpers.js @@ -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}`; diff --git a/spec/frontend/deploy_freeze/store/actions_spec.js b/spec/frontend/deploy_freeze/store/actions_spec.js index 97f94cdbf5e..3c9d25c4f5c 100644 --- a/spec/frontend/deploy_freeze/store/actions_spec.js +++ b/spec/frontend/deploy_freeze/store/actions_spec.js @@ -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); diff --git a/spec/frontend/deploy_freeze/store/mutations_spec.js b/spec/frontend/deploy_freeze/store/mutations_spec.js index 0453e037e15..7cb208f16b2 100644 --- a/spec/frontend/deploy_freeze/store/mutations_spec.js +++ b/spec/frontend/deploy_freeze/store/mutations_spec.js @@ -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); diff --git a/spec/frontend/fixtures/freeze_period.rb b/spec/frontend/fixtures/freeze_period.rb index 7695dbc2e8f..193bd0c3ef2 100644 --- a/spec/frontend/fixtures/freeze_period.rb +++ b/spec/frontend/fixtures/freeze_period.rb @@ -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 diff --git a/spec/graphql/resolvers/ci/runner_setup_resolver_spec.rb b/spec/graphql/resolvers/ci/runner_setup_resolver_spec.rb index e6f76c8cd2d..3d004290d9b 100644 --- a/spec/graphql/resolvers/ci/runner_setup_resolver_spec.rb +++ b/spec/graphql/resolvers/ci/runner_setup_resolver_spec.rb @@ -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 'with container platforms' do + let(:platform) { 'docker' } + let(:project) { create(:project) } + let(:target_param) { { project_id: project.to_global_id } } - context 'when user is not admin' do - it 'returns access error' do - expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable) - end + it 'returns install instructions' do + expect(resolve_subject[:install_instructions]).not_to eq(nil) 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 + it 'does not return register instructions' do + expect(resolve_subject[:register_instructions]).to eq(nil) end end - context 'with project target parameter' do - let(:project) { create(:project) } - let(:target_param) { { project_id: project.to_global_id } } + context 'with regular platforms' do + let(:platform) { 'linux' } - context 'when user has access to admin builds on project' do - before do - project.add_maintainer(user) - end + context 'without target parameter' do + let(:target_param) { {} } - 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 not admin' do + it 'returns access error' do + expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable) + end end - end - context 'when user does not have access to admin builds on project' do - before do - project.add_developer(user) - end + context 'when user is admin' do + before do + user.update!(admin: true) + end - it 'returns access error' do - expect { resolve_subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable) + 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 - end - context 'with group target parameter' do - let(:group) { create(:group) } - let(:target_param) { { group_id: group.to_global_id } } + 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 - context 'when user has access to admin builds on group' do - before do - group.add_owner(user) + 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 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 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 'when user does not have access to admin builds on group' do - before do - group.add_developer(user) + 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 - 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 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 diff --git a/spec/lib/gitlab/ci/runner_instructions_spec.rb b/spec/lib/gitlab/ci/runner_instructions_spec.rb index 32ee2ceb040..d1020026fe6 100644 --- a/spec/lib/gitlab/ci/runner_instructions_spec.rb +++ b/spec/lib/gitlab/ci/runner_instructions_spec.rb @@ -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 diff --git a/spec/lib/gitlab/experimentation_spec.rb b/spec/lib/gitlab/experimentation_spec.rb index 1003153d92b..238392e2067 100644 --- a/spec/lib/gitlab/experimentation_spec.rb +++ b/spec/lib/gitlab/experimentation_spec.rb @@ -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, |