root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-02-25 18:11:05 +00:00
parent c00ed91073
commit 01ae05ffd1
58 changed files with 491 additions and 315 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
app/controllers/projects/ci/daily_build_group_report_results_controller.rb
View File

@ -1,10 +1,6 @@
# frozen_string_literal: true
class Projects::Ci::DailyBuildGroupReportResultsController < Projects::ApplicationController
include Gitlab::Utils::StrongMemoize
REPORT_WINDOW = 90.days
before_action :authorize_read_build_report_results!
before_action :validate_param_type!
@ -49,28 +45,13 @@ class Projects::Ci::DailyBuildGroupReportResultsController < Projects::Applicati
{
project: project,
coverage: true,
start_date: start_date,
end_date: end_date,
start_date: params[:start_date],
end_date: params[:end_date],
ref_path: params[:ref_path],
sort: true
}
end
def start_date
strong_memoize(:start_date) do
start_date = Date.parse(params.require(:start_date))
# The start_date cannot be older than `end_date - 90 days`
[start_date, end_date - REPORT_WINDOW].max
end
end
def end_date
strong_memoize(:end_date) do
Date.parse(params.require(:end_date))
end
end
def allowed_param_types
Ci::DailyBuildGroupReportResult::PARAM_TYPES
end

2
app/controllers/projects/graphs_controller.rb
View File

@ -62,7 +62,7 @@ class Projects::GraphsController < Projects::ApplicationController
return unless can?(current_user, :read_build_report_results, project)
date_today = Date.current
report_window = Projects::Ci::DailyBuildGroupReportResultsController::REPORT_WINDOW
report_window = ::Ci::DailyBuildGroupReportResultsFinder::REPORT_WINDOW
@daily_coverage_options = {
base_params: {

6
app/controllers/search_controller.rb
View File

@ -49,6 +49,12 @@ class SearchController < ApplicationController
scope = search_service.scope
count = search_service.search_results.formatted_count(scope)
# Users switching tabs will keep fetching the same tab counts so it's a
# good idea to cache in their browser just for a short time. They can still
# clear cache if they are seeing an incorrect count but inaccurate count is
# not such a bad thing.
expires_in 1.minute
render json: { count: count }
end

19
app/finders/ci/daily_build_group_report_results_finder.rb
View File

@ -11,8 +11,8 @@
# group: integer
# coverage: boolean
# ref_path: string
# start_date: date
# end_date: date
# start_date: string
# end_date: string
# sort: boolean
# limit: integer
@ -21,6 +21,8 @@ module Ci
include Gitlab::Allowable
MAX_ITEMS = 1_000
REPORT_WINDOW = 90.days
DATE_FORMAT_ALLOWED = '%Y-%m-%d'
attr_reader :params, :current_user
@ -62,7 +64,7 @@ module Ci
end
def by_dates(items)
params[:start_date].present? && params[:end_date].present? ? items.by_dates(params[:start_date], params[:end_date]) : items
params[:start_date].present? && params[:end_date].present? ? items.by_dates(start_date, end_date) : items
end
def sort(items)
@ -80,6 +82,17 @@ module Ci
[params[:limit].to_i, MAX_ITEMS].min
end
def start_date
start_date = Date.strptime(params[:start_date], DATE_FORMAT_ALLOWED) rescue REPORT_WINDOW.ago.to_date
# The start_date cannot be older than `end_date - 90 days`
[start_date, end_date - REPORT_WINDOW].max
end
def end_date
Date.strptime(params[:end_date], DATE_FORMAT_ALLOWED) rescue Date.current
end
end
end

1
app/models/onboarding_progress.rb
View File

@ -17,6 +17,7 @@ class OnboardingProgress < ApplicationRecord
:code_owners_enabled,
:scoped_label_created,
:security_scan_enabled,
:issue_created,
:issue_auto_closed,
:repository_imported,
:repository_mirrored

1
app/services/issues/create_service.rb
View File

@ -28,6 +28,7 @@ module Issues
issue.run_after_commit do
NewIssueWorker.perform_async(issue.id, user.id)
IssuePlacementWorker.perform_async(nil, issue.project_id)
Namespaces::OnboardingIssueCreatedWorker.perform_async(issue.namespace.id)
end
end

8
app/workers/all_queues.yml
View File

@ -1840,6 +1840,14 @@
:weight: 1
:idempotent:
:tags: []
- :name: namespaces_onboarding_issue_created
:feature_category: :issue_tracking
:has_external_dependencies:
:urgency: :low
:resource_boundary: :unknown
:weight: 1
:idempotent: true
:tags: []
- :name: namespaces_onboarding_pipeline_created
:feature_category: :subgroups
:has_external_dependencies:

20
app/workers/namespaces/onboarding_issue_created_worker.rb Normal file
View File

@ -0,0 +1,20 @@
# frozen_string_literal: true
module Namespaces
class OnboardingIssueCreatedWorker
include ApplicationWorker
feature_category :issue_tracking
urgency :low
deduplicate :until_executing
idempotent!
def perform(namespace_id)
namespace = Namespace.find_by_id(namespace_id)
return unless namespace
OnboardingProgressService.new(namespace).execute(action: :issue_created)
end
end
end

5
changelogs/unreleased/277327-fix-background-migration-argument-type.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Fix argument type for background migration
merge_request: 55097
author:
type: fixed

5
changelogs/unreleased/300150-cache-search-tab-counters.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Cache /search/count requests in the browser
merge_request: 55036
author:
type: performance

5
changelogs/unreleased/nakayoshi-default-enabled.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Enable `nakayoshi_fork` by default
merge_request: 54688
author:
type: other

5
changelogs/unreleased/nicolasdular-record-issue-creation-onboarding-progress.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Record onboarding action for issue creation
merge_request: 53611
author:
type: changed

2
config/puma.example.development.rb
View File

@ -86,7 +86,7 @@ end
# https://github.com/puma/puma/blob/master/5.0-Upgrade.md#nakayoshi_fork
if defined?(nakayoshi_fork)
nakayoshi_fork if ENV['ENABLE_PUMA_NAKAYOSHI_FORK'] == 'true'
nakayoshi_fork unless ENV['DISABLE_PUMA_NAKAYOSHI_FORK'] == 'true'
end
# Use json formatter

2
config/puma.rb.example
View File

@ -76,7 +76,7 @@ end
# https://github.com/puma/puma/blob/master/5.0-Upgrade.md#nakayoshi_fork
if defined?(nakayoshi_fork)
nakayoshi_fork if ENV['ENABLE_PUMA_NAKAYOSHI_FORK'] == 'true'
nakayoshi_fork unless ENV['DISABLE_PUMA_NAKAYOSHI_FORK'] == 'true'
end
# Use json formatter

2
config/puma_actioncable.example.development.rb
View File

@ -86,7 +86,7 @@ end
# https://github.com/puma/puma/blob/master/5.0-Upgrade.md#nakayoshi_fork
if defined?(nakayoshi_fork)
nakayoshi_fork if ENV['ENABLE_PUMA_NAKAYOSHI_FORK'] == 'true'
nakayoshi_fork unless ENV['DISABLE_PUMA_NAKAYOSHI_FORK'] == 'true'
end
# Use json formatter

2
config/sidekiq_queues.yml
View File

@ -212,6 +212,8 @@
- 1
- - namespaceless_project_destroy
- 1
- - namespaces_onboarding_issue_created
- 1
- - namespaces_onboarding_pipeline_created
- 1
- - namespaces_onboarding_progress

9
db/migrate/20210208103243_add_issue_created_at_to_onboarding_progress.rb Normal file
View File

@ -0,0 +1,9 @@
# frozen_string_literal: true
class AddIssueCreatedAtToOnboardingProgress < ActiveRecord::Migration[6.0]
DOWNTIME = false
def change
add_column :onboarding_progresses, :issue_created_at, :datetime_with_timezone
end
end

8
db/post_migrate/20210111075105_schedule_uuid_population_for_security_findings.rb
View File

@ -11,13 +11,7 @@ class ScheduleUuidPopulationForSecurityFindings < ActiveRecord::Migration[6.0]
disable_ddl_transaction!
def up
Gitlab::BackgroundMigration::PopulateUuidsForSecurityFindings.security_findings.each_batch(column: :scan_id, of: BATCH_SIZE) do |batch, index|
migrate_in(
DELAY_INTERVAL * index,
MIGRATION_CLASS,
batch.pluck(:scan_id)
)
end
# no-op, replaced by 20210111075206_schedule_uuid_population_for_security_findings2.rb
end
def down

34
db/post_migrate/20210111075206_schedule_uuid_population_for_security_findings2.rb Normal file
View File

@ -0,0 +1,34 @@
# frozen_string_literal: true
# This replaces the previous post-deployment migration 20210111075105_schedule_uuid_population_for_security_findings.rb,
# we have to run this again due to a bug in how we were receiving the arguments in the background migration.
class ScheduleUuidPopulationForSecurityFindings2 < ActiveRecord::Migration[6.0]
include Gitlab::Database::MigrationHelpers
DOWNTIME = false
MIGRATION_CLASS = 'PopulateUuidsForSecurityFindings'
DELAY_INTERVAL = 2.minutes
BATCH_SIZE = 25
disable_ddl_transaction!
def up
::Gitlab::BackgroundMigration.steal(MIGRATION_CLASS) do |job|
job.delete
false
end
Gitlab::BackgroundMigration::PopulateUuidsForSecurityFindings.security_findings.each_batch(column: :scan_id, of: BATCH_SIZE) do |batch, index|
migrate_in(
DELAY_INTERVAL * index,
MIGRATION_CLASS,
batch.pluck(:scan_id)
)
end
end
def down
# no-op
end
end

1
db/schema_migrations/20210111075206 Normal file
View File

@ -0,0 +1 @@
9da5955d9f71d671a41e6d03f76f87370d6e67b6853707adb164f7ffa8c75082

1
db/schema_migrations/20210208103243 Normal file
View File

@ -0,0 +1 @@
039962e291f9adde52379cac8f8278aa1b339d973fb33ae40ea7d8dc3e113fb6

3
db/structure.sql
View File

@ -14694,7 +14694,8 @@ CREATE TABLE onboarding_progresses (
security_scan_enabled_at timestamp with time zone,
issue_auto_closed_at timestamp with time zone,
repository_imported_at timestamp with time zone,
repository_mirrored_at timestamp with time zone
repository_mirrored_at timestamp with time zone,
issue_created_at timestamp with time zone
);
CREATE SEQUENCE onboarding_progresses_id_seq

1
doc/.vale/gitlab/SubstitutionSuggestions.yml
View File

@ -14,6 +14,7 @@ swap:
active user: '"billable user"'
active users: '"billable users"'
docs: '"documentation"'
GFM: '"GitLab Flavored Markdown"'
once that: '"after that"'
once the: '"after the"'
once you: '"after you"'

2
doc/ci/examples/deployment/README.md
View File

@ -128,4 +128,4 @@ or `%` (for Windows Batch runners):
1. `$VARIABLE` - use it for non-Windows runners
1. `%VARIABLE%` - use it for Windows Batch runners
Read more about the [CI variables](../../variables/README.md).
Read more about the [CI/CD variables](../../variables/README.md).

2
doc/ci/variables/README.md
View File

@ -161,7 +161,7 @@ You can use tools like [the AWS CLI](https://docs.aws.amazon.com/cli/latest/user
and [`kubectl`](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/#the-kubeconfig-environment-variable)
to customize your configuration by using **File** type variables.
Previously, a common pattern was to read the value of a CI variable, save it in a file, and then
Previously, a common pattern was to read the value of a CI/CD variable, save it in a file, and then
use that file in your script:
```shell

282
doc/ci/variables/predefined_variables.md
View File

@ -7,142 +7,158 @@ type: reference
# Predefined variables reference
For an introduction on this subject, read through the
[CI/CD variables](README.md) document.
Predefined [CI/CD variables](README.md) are available in every GitLab CI/CD pipeline.
Some of the predefined variables are available only if a minimum
version of [GitLab Runner](https://docs.gitlab.com/runner/) is used. Consult the table below to find the
version of GitLab Runner that's required.
Some variables are only available with more recent versions of [GitLab Runner](https://docs.gitlab.com/runner/).
You can add a command to your `.gitlab-ci.yml` file to
[output the values of all variables available for a job](README.md#list-all-environment-variables).
You can [output the values of all variables available for a job](README.md#list-all-environment-variables)
with a `script` command.
Kubernetes-specific variables are detailed in the
[Kubernetes deployment variables](../../user/project/clusters/index.md#deployment-variables) section.
There are also [Kubernetes-specific deployment variables](../../user/project/clusters/index.md#deployment-variables).
| Variable | GitLab | Runner | Description |
|------------------------------------------|--------|--------|-------------|
| `CHAT_CHANNEL` | 10.6 | all | The Source chat channel that triggered the [ChatOps](../chatops/index.md) command. |
| `CHAT_INPUT` | 10.6 | all | The additional arguments passed with the [ChatOps](../chatops/index.md) command. |
| `CI` | all | 0.4 | Available for all jobs executed in CI/CD. `true` when available. |
| `CI_API_V4_URL` | 11.7 | all | The GitLab API v4 root URL. |
| `CI_BUILDS_DIR` | all | 11.10 | The top-level directory where builds are executed. |
| `CI_COMMIT_BEFORE_SHA` | 11.2 | all | The previous latest commit present on a branch. Is always `0000000000000000000000000000000000000000` in pipelines for merge requests. |
| `CI_COMMIT_BRANCH` | 12.6 | 0.5 | The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines. |
| `CI_COMMIT_DESCRIPTION` | 10.8 | all | The description of the commit. If the title is shorter than 100 characters, the message without the first line. |
| `CI_COMMIT_MESSAGE` | 10.8 | all | The full commit message. |
| `CI_COMMIT_REF_NAME` | 9.0 | all | The branch or tag name for which project is built. |
| `CI_COMMIT_REF_PROTECTED` | 11.11 | all | `true` if the job is running for a protected reference. |
| `CI_COMMIT_REF_SLUG` | 9.0 | all | `CI_COMMIT_REF_NAME` in lowercase, shortened to 63 bytes, and with everything except `0-9` and `a-z` replaced with `-`. No leading / trailing `-`. Use in URLs, host names and domain names. |
| `CI_COMMIT_SHA` | 9.0 | all | The commit revision the project is built for. |
| `CI_COMMIT_SHORT_SHA` | 11.7 | all | The first eight characters of `CI_COMMIT_SHA`. |
| `CI_COMMIT_TAG` | 9.0 | 0.5 | The commit tag name. Available only in pipelines for tags. |
| `CI_COMMIT_TIMESTAMP` | 13.4 | all | The timestamp of the commit in the ISO 8601 format. |
| `CI_COMMIT_TITLE` | 10.8 | all | The title of the commit. The full first line of the message. |
| `CI_CONCURRENT_ID` | all | 11.10 | The unique ID of build execution in a single executor. |
| `CI_CONCURRENT_PROJECT_ID` | all | 11.10 | The unique ID of build execution in a single executor and project. |
| `CI_CONFIG_PATH` | 9.4 | 0.5 | The path to the CI/CD configuration file. Defaults to `.gitlab-ci.yml`. |
| `CI_DEBUG_TRACE` | all | 1.7 | `true` if [debug logging (tracing)](README.md#debug-logging) is enabled. |
| `CI_DEFAULT_BRANCH` | 12.4 | all | The name of the project's default branch. |
| `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX` | 13.7 | all | The image prefix for pulling images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_PASSWORD` | 13.7 | all | The password to pull images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_SERVER` | 13.7 | all | The server for logging in to the Dependency Proxy. This is equivalent to `$CI_SERVER_HOST:$CI_SERVER_PORT`. |
| `CI_DEPENDENCY_PROXY_USER` | 13.7 | all | The username to pull images through the Dependency Proxy. |
| `CI_DEPLOY_FREEZE` | 13.2 | all | Only available if the pipeline runs during a [deploy freeze window](../../user/project/releases/index.md#prevent-unintentional-releases-by-setting-a-deploy-freeze). `true` when available. |
| `CI_DEPLOY_PASSWORD` | 10.8 | all | The authentication password of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. |
| `CI_DEPLOY_USER` | 10.8 | all | The authentication username of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. |
| `CI_DISPOSABLE_ENVIRONMENT` | all | 10.1 | Only available if the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). `true` when available. |
| `CI_ENVIRONMENT_NAME` | 8.15 | all | The name of the environment for this job. Available if [`environment:name`](../yaml/README.md#environmentname) is set. |
| `CI_ENVIRONMENT_SLUG` | 8.15 | all | The simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Available if [`environment:name`](../yaml/README.md#environmentname) is set. |
| `CI_ENVIRONMENT_URL` | 9.3 | all | The URL of the environment for this job. Available if [`environment:url`](../yaml/README.md#environmenturl) is set. |
| `CI_HAS_OPEN_REQUIREMENTS` | 13.1 | all | Only available if the pipeline's project has an open [requirement](../../user/project/requirements/index.md). `true` when available. |
| `CI_JOB_ID` | 9.0 | all | The internal ID of the job, unique across all jobs in the GitLab instance. |
| `CI_JOB_IMAGE` | 12.9 | 12.9 | The name of the Docker image running the job. |
| `CI_JOB_JWT` | 12.10 | all | A RS256 JSON web token to authenticate with third party systems that support JWT authentication, for example [HashiCorp's Vault](../secrets/index.md). |
| `CI_JOB_MANUAL` | 8.12 | all | `true` if a job was started manually. |
| `CI_JOB_NAME` | 9.0 | 0.5 | The name of the job. |
| `CI_JOB_STAGE` | 9.0 | 0.5 | The name of the job's stage. |
| `CI_JOB_STATUS` | all | 13.5 | The status of the job as each runner stage is executed. Use with [`after_script`](../yaml/README.md#after_script). Can be `success`, `failed`, or `canceled`. |
| `CI_JOB_TOKEN` | 9.0 | 1.2 | A token to authenticate with [certain API endpoints](../../api/README.md#gitlab-ci-job-token) or download [dependent repositories](../../user/project/new_ci_build_permissions_model.md#dependent-repositories). The token is valid as long as the job is running. |
| `CI_JOB_URL` | 11.1 | 0.5 | The job details URL. |
| `CI_KUBERNETES_ACTIVE` | 13.0 | all | Only available if the pipeline has a Kubernetes cluster available for deployments. `true` when available. |
| `CI_NODE_INDEX` | 11.5 | all | The index of the job in the job set. Only available if the job uses [`parallel`](../yaml/README.md#parallel). |
| `CI_NODE_TOTAL` | 11.5 | all | The total number of instances of this job running in parallel. Set to `1` if the job does not use [`parallel`](../yaml/README.md#parallel). |
| `CI_OPEN_MERGE_REQUESTS` | 13.8 | all | A comma-separated list of up to four merge requests that use the current branch and project as the merge request source. Only available in branch and merge request pipelines if the branch has an associated merge request. For example, `gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11`. |
| `CI_PAGES_DOMAIN` | 11.8 | all | The configured domain that hosts GitLab Pages. |
| `CI_PAGES_URL` | 11.8 | all | The URL for a GitLab Pages site. Always a subdomain of `CI_PAGES_DOMAIN`. |
| `CI_PIPELINE_ID` | 8.10 | all | The instance-level ID of the current pipeline. This ID is unique across all projects on the GitLab instance. |
| `CI_PIPELINE_IID` | 11.0 | all | The project-level IID (internal ID) of the current pipeline. This ID is unique only within the current project. |
| `CI_PIPELINE_SOURCE` | 10.0 | all | How the pipeline was triggered. Can be `push`, `web`, `schedule`, `api`, `external`, `chat`, `webide`, `merge_request_event`, `external_pull_request_event`, `parent_pipeline`, [`trigger`, or `pipeline`](../triggers/README.md#authentication-tokens). |
| `CI_PIPELINE_TRIGGERED` | all | all | `true` if the job was [triggered](../triggers/README.md). |
| `CI_PIPELINE_URL` | 11.1 | 0.5 | The URL for the pipeline details. |
| `CI_PROJECT_CONFIG_PATH` | 13.8 | all | The CI/CD configuration path for the project. |
| `CI_PROJECT_DIR` | all | all | The full path the repository is cloned to, and where the job runs from. If the GitLab Runner `builds_dir` parameter is set, this variable is set relative to the value of `builds_dir`. For more information, see the [Advanced GitLab Runner configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section). |
| `CI_PROJECT_ID` | all | all | The ID of the current project. This ID is unique across all projects on the GitLab instance. |
| `CI_PROJECT_NAME` | 8.10 | 0.5 | The name of the directory for the project. For example if the project URL is `gitlab.example.com/group-name/project-1`, `CI_PROJECT_NAME` is `project-1`. |
| `CI_PROJECT_NAMESPACE` | 8.10 | 0.5 | The project namespace (username or group name) of the job. |
| `CI_PROJECT_PATH_SLUG` | 9.3 | all | `$CI_PROJECT_PATH` in lowercase with characters that are not `a-z` or `0-9` replaced with `-`. Use in URLs and domain names. |
| `CI_PROJECT_PATH` | 8.10 | 0.5 | The project namespace with the project name included. |
| `CI_PROJECT_REPOSITORY_LANGUAGES` | 12.3 | all | A comma-separated, lowercase list of the languages used in the repository. For example `ruby,javascript,html,css`. |
| `CI_PROJECT_ROOT_NAMESPACE` | 13.2 | 0.5 | The root project namespace (username or group name) of the job. For example, if `CI_PROJECT_NAMESPACE` is `root-group/child-group/grandchild-group`, `CI_PROJECT_ROOT_NAMESPACE` is `root-group`. |
| `CI_PROJECT_TITLE` | 12.4 | all | The human-readable project name as displayed in the GitLab web interface. |
| `CI_PROJECT_URL` | 8.10 | 0.5 | The HTTP(S) address of the project. |
| `CI_PROJECT_VISIBILITY` | 10.3 | all | The project visibility. Can be `internal`, `private`, or `public`. |
| `CI_REGISTRY_IMAGE` | 8.10 | 0.5 | The address of the project's Container Registry. Only available if the Container Registry is enabled for the project. |
| `CI_REGISTRY_PASSWORD` | 9.0 | all | The password to push containers to the project's GitLab Container Registry. Only available if the Container Registry is enabled for the project. |
| `CI_REGISTRY_USER` | 9.0 | all | The username to push containers to the project's GitLab Container Registry. Only available if the Container Registry is enabled for the project. |
| `CI_REGISTRY` | 8.10 | 0.5 | The address of the GitLab Container Registry. Only available if the Container Registry is enabled for the project. This variable includes a `:port` value if one is specified in the registry configuration. |
| `CI_REPOSITORY_URL` | 9.0 | all | The URL to clone the Git repository. |
| `CI_RUNNER_DESCRIPTION` | 8.10 | 0.5 | The description of the runner. |
| `CI_RUNNER_EXECUTABLE_ARCH` | all | 10.6 | The OS/architecture of the GitLab Runner executable. Might not be the same as the environment of the executor. |
| `CI_RUNNER_ID` | 8.10 | 0.5 | The unique ID of the runner being used. |
| `CI_RUNNER_REVISION` | all | 10.6 | The revision of the runner running the job. |
| `CI_RUNNER_SHORT_TOKEN` | all | 12.3 | First eight characters of the runner's token used to authenticate new job requests. Used as the runner's unique ID. |
| `CI_RUNNER_TAGS` | 8.10 | 0.5 | A comma-separated list of the runner tags. |
| `CI_RUNNER_VERSION` | all | 10.6 | The version of the GitLab Runner running the job. |
| `CI_SERVER_HOST` | 12.1 | all | The host of the GitLab instance URL, without protocol or port. For example `gitlab.example.com`. |
| `CI_SERVER_NAME` | all | all | The name of CI/CD server that coordinates jobs. |
| `CI_SERVER_PORT` | 12.8 | all | The port of the GitLab instance URL, without host or protocol. For example `8080`. |
| `CI_SERVER_PROTOCOL` | 12.8 | all | The protocol of the GitLab instance URL, without host or port. For example `https`. |
| `CI_SERVER_REVISION` | all | all | GitLab revision that schedules jobs. |
| `CI_SERVER_URL` | 12.7 | all | The base URL of the GitLab instance, including protocol and port. For example `https://gitlab.example.com:8080`. |
| `CI_SERVER_VERSION_MAJOR` | 11.4 | all | The major version of the GitLab instance. For example, if the GitLab version is `13.6.1`, the `CI_SERVER_VERSION_MAJOR` is `13`. |
| `CI_SERVER_VERSION_MINOR` | 11.4 | all | The minor version of the GitLab instance. For example, if the GitLab version is `13.6.1`, the `CI_SERVER_VERSION_MINOR` is `6`. |
| `CI_SERVER_VERSION_PATCH` | 11.4 | all | The patch version of the GitLab instance. For example, if the GitLab version is `13.6.1`, the `CI_SERVER_VERSION_PATCH` is `1`. |
| `CI_SERVER_VERSION` | all | all | The full version of the GitLab instance. |
| `CI_SERVER` | all | all | Available for all jobs executed in CI/CD. `yes` when available. |
| `CI_SHARED_ENVIRONMENT` | all | 10.1 | Only available if the job is executed in a shared environment (something that is persisted across CI/CD invocations, like the `shell` or `ssh` executor). `true` when available. |
| `GITLAB_CI` | all | all | Available for all jobs executed in CI/CD. `true` when available. |
| `GITLAB_FEATURES` | 10.6 | all | The comma-separated list of licensed features available for the GitLab instance and license. |
| `GITLAB_USER_EMAIL` | 8.12 | all | The email of the user who started the job. |
| `GITLAB_USER_ID` | 8.12 | all | The ID of the user who started the job. |
| `GITLAB_USER_LOGIN` | 10.0 | all | The username of the user who started the job. |
| `GITLAB_USER_NAME` | 10.0 | all | The name of the user who started the job. |
| `TRIGGER_PAYLOAD` | 13.9 | all | The webhook payload. Only available when a pipeline is [triggered with a webhook](../triggers/README.md#using-webhook-payload-in-the-triggered-pipeline). |
## Predefined variables for merge request pipelines
These variables are available when:
- The pipelines [are merge request pipelines](../merge_request_pipelines/index.md).
- The merge request is open.
| Variable | GitLab | Runner | Description |
|----------------------------------------|--------|--------|-------------|
| `CI_MERGE_REQUEST_ASSIGNEES` | 11.9 | all | Comma-separated list of usernames of assignees for the merge request. |
| `CI_MERGE_REQUEST_ID` | 11.6 | all | The instance-level ID of the merge request. This is a unique ID across all projects on GitLab. |
| `CI_MERGE_REQUEST_IID` | 11.6 | all | The project-level IID (internal ID) of the merge request. This ID is unique for the current project. |
| `CI_MERGE_REQUEST_LABELS` | 11.9 | all | Comma-separated label names of the merge request. |
| `CI_MERGE_REQUEST_MILESTONE` | 11.9 | all | The milestone title of the merge request. |
| `CI_MERGE_REQUEST_PROJECT_ID` | 11.6 | all | The ID of the project of the merge request. |
| `CI_MERGE_REQUEST_PROJECT_PATH` | 11.6 | all | The path of the project of the merge request. For example `namespace/awesome-project`. |
| `CI_MERGE_REQUEST_PROJECT_URL` | 11.6 | all | The URL of the project of the merge request. For example, `http://192.168.10.15:3000/namespace/awesome-project`. |
| `CI_MERGE_REQUEST_REF_PATH` | 11.6 | all | The ref path of the merge request. For example, `refs/merge-requests/1/head`. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` | 11.6 | all | The source branch name of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request. Only available in [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_ID` | 11.6 | all | The ID of the source project of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` | 11.6 | all | The path of the source project of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_URL` | 11.6 | all | The URL of the source project of the merge request. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` | 11.6 | all | The target branch name of the merge request. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request. Only available in [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_TITLE` | 11.9 | all | The title of the merge request. |
| `CI_MERGE_REQUEST_EVENT_TYPE` | 12.3 | all | The event type of the merge request. Can be `detached`, `merged_result` or `merge_train`. |
| `CI_MERGE_REQUEST_DIFF_ID` | 13.7 | all | The version of the merge request diff. |
| `CI_MERGE_REQUEST_DIFF_BASE_SHA` | 13.7 | all | The base SHA of the merge request diff. |
## Predefined variables for external pull request pipelines
These variables are only available when:
- The pipelines are [external pull requests pipelines](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests)
- The pull request is open.
| Variable | GitLab | Runner | Description |
|-----------------------------------------------|--------|--------|-------------|
| `CHAT_CHANNEL` | 10.6 | all | Source chat channel which triggered the [ChatOps](../chatops/index.md) command. |
| `CHAT_INPUT` | 10.6 | all | Additional arguments passed in the [ChatOps](../chatops/index.md) command. |
| `CI` | all | 0.4 | Mark that job is executed in CI environment. |
| `CI_API_V4_URL` | 11.7 | all | The GitLab API v4 root URL. |
| `CI_BUILDS_DIR` | all | 11.10 | Top-level directory where builds are executed. |
| `CI_COMMIT_BEFORE_SHA` | 11.2 | all | The previous latest commit present on a branch. Is always `0000000000000000000000000000000000000000` in pipelines for merge requests. |
| `CI_COMMIT_DESCRIPTION` | 10.8 | all | The description of the commit: the message without first line, if the title is shorter than 100 characters; full message in other case. |
| `CI_COMMIT_MESSAGE` | 10.8 | all | The full commit message. |
| `CI_COMMIT_REF_NAME` | 9.0 | all | The branch or tag name for which project is built. |
| `CI_COMMIT_REF_PROTECTED` | 11.11 | all | `true` if the job is running on a protected reference, `false` if not. |
| `CI_COMMIT_REF_SLUG` | 9.0 | all | `$CI_COMMIT_REF_NAME` in lowercase, shortened to 63 bytes, and with everything except `0-9` and `a-z` replaced with `-`. No leading / trailing `-`. Use in URLs, host names and domain names. |
| `CI_COMMIT_SHA` | 9.0 | all | The commit revision for which project is built. |
| `CI_COMMIT_SHORT_SHA` | 11.7 | all | The first eight characters of `CI_COMMIT_SHA`. |
| `CI_COMMIT_BRANCH` | 12.6 | 0.5 | The commit branch name. Present in branch pipelines, including pipelines for the default branch. Not present in merge request pipelines or tag pipelines. |
| `CI_COMMIT_TAG` | 9.0 | 0.5 | The commit tag name. Present only when building tags. |
| `CI_COMMIT_TITLE` | 10.8 | all | The title of the commit - the full first line of the message. |
| `CI_COMMIT_TIMESTAMP` | 13.4 | all | The timestamp of the commit in the ISO 8601 format. |
| `CI_CONCURRENT_ID` | all | 11.10 | Unique ID of build execution in a single executor. |
| `CI_CONCURRENT_PROJECT_ID` | all | 11.10 | Unique ID of build execution in a single executor and project. |
| `CI_CONFIG_PATH` | 9.4 | 0.5 | The path to CI configuration file. Defaults to `.gitlab-ci.yml`. |
| `CI_DEBUG_TRACE` | all | 1.7 | Whether [debug logging (tracing)](README.md#debug-logging) is enabled. |
| `CI_DEFAULT_BRANCH` | 12.4 | all | The name of the default branch for the project. |
| `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX` | 13.7 | all | The image prefix for pulling images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_SERVER` | 13.7 | all | The server for logging in to the Dependency Proxy. This is equivalent to `$CI_SERVER_HOST:$CI_SERVER_PORT`. |
| `CI_DEPENDENCY_PROXY_PASSWORD` | 13.7 | all | The password to use to pull images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_USER` | 13.7 | all | The username to use to pull images through the Dependency Proxy. |
| `CI_DEPLOY_FREEZE` | 13.2 | all | Included with the value `true` if the pipeline runs during a [deploy freeze window](../../user/project/releases/index.md#prevent-unintentional-releases-by-setting-a-deploy-freeze). |
| `CI_DEPLOY_PASSWORD` | 10.8 | all | Authentication password of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), only present if the Project has one related. |
| `CI_DEPLOY_USER` | 10.8 | all | Authentication username of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), only present if the Project has one related. |
| `CI_DISPOSABLE_ENVIRONMENT` | all | 10.1 | Marks that the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). If the environment is disposable, it is set to true, otherwise it is not defined at all. |
| `CI_ENVIRONMENT_NAME` | 8.15 | all | The name of the environment for this job. Only present if [`environment:name`](../yaml/README.md#environmentname) is set. |
| `CI_ENVIRONMENT_SLUG` | 8.15 | all | A simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Only present if [`environment:name`](../yaml/README.md#environmentname) is set. |
| `CI_ENVIRONMENT_URL` | 9.3 | all | The URL of the environment for this job. Only present if [`environment:url`](../yaml/README.md#environmenturl) is set. |
| `CI_EXTERNAL_PULL_REQUEST_IID` | 12.3 | all | Pull Request ID from GitHub if the [pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_REPOSITORY` | 13.3 | all | The source repository name of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_REPOSITORY` | 13.3 | all | The target repository name of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_NAME` | 12.3 | all | The source branch name of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHA` | 12.3 | all | The HEAD SHA of the source branch of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAME` | 12.3 | all | The target branch name of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHA` | 12.3 | all | The HEAD SHA of the target branch of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open. |
| `CI_HAS_OPEN_REQUIREMENTS` | 13.1 | all | Included with the value `true` only if the pipeline's project has any open [requirements](../../user/project/requirements/index.md). Not included if there are no open requirements for the pipeline's project. |
| `CI_OPEN_MERGE_REQUESTS` | 13.8 | all | Available in branch and merge request pipelines. Contains a comma-separated list of up to four merge requests that use the current branch and project as the merge request source. For example `gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11`. |
| `CI_JOB_ID` | 9.0 | all | The unique ID of the current job that GitLab CI/CD uses internally. |
| `CI_JOB_IMAGE` | 12.9 | 12.9 | The name of the image running the CI job. |
| `CI_JOB_MANUAL` | 8.12 | all | The flag to indicate that job was manually started. |
| `CI_JOB_NAME` | 9.0 | 0.5 | The name of the job as defined in `.gitlab-ci.yml`. |
| `CI_JOB_STAGE` | 9.0 | 0.5 | The name of the stage as defined in `.gitlab-ci.yml`. |
| `CI_JOB_STATUS` | all | 13.5 | The state of the job as each runner stage is executed. Use with [`after_script`](../yaml/README.md#after_script) where `CI_JOB_STATUS` can be either: `success`, `failed` or `canceled`. |
| `CI_JOB_TOKEN` | 9.0 | 1.2 | Token used for authenticating with [a few API endpoints](../../api/README.md#gitlab-ci-job-token) and downloading [dependent repositories](../../user/project/new_ci_build_permissions_model.md#dependent-repositories). The token is valid as long as the job is running. |
| `CI_JOB_JWT` | 12.10 | all | RS256 JSON web token that can be used for authenticating with third party systems that support JWT authentication, for example [HashiCorp's Vault](../secrets/index.md). |
| `CI_JOB_URL` | 11.1 | 0.5 | Job details URL. |
| `CI_KUBERNETES_ACTIVE` | 13.0 | all | Included with the value `true` only if the pipeline has a Kubernetes cluster available for deployments. Not included if no cluster is available. Can be used as an alternative to [`only:kubernetes`/`except:kubernetes`](../yaml/README.md#onlykubernetesexceptkubernetes) with [`rules:if`](../yaml/README.md#rulesif). |
| `CI_MERGE_REQUEST_ASSIGNEES` | 11.9 | all | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_ID` | 11.6 | all | The instance-level ID of the merge request. Only available if [the pipelines are for merge requests](../merge_request_pipelines/index.md) and the merge request is created. This is a unique ID across all projects on GitLab. |
| `CI_MERGE_REQUEST_IID` | 11.6 | all | The project-level IID (internal ID) of the merge request. Only available If [the pipelines are for merge requests](../merge_request_pipelines/index.md) and the merge request is created. This ID is unique for the current project. |
| `CI_MERGE_REQUEST_LABELS` | 11.9 | all | Comma-separated label names of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_MILESTONE` | 11.9 | all | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_PROJECT_ID` | 11.6 | all | The ID of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_PROJECT_PATH` | 11.6 | all | The path of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (for example `namespace/awesome-project`). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_PROJECT_URL` | 11.6 | all | The URL of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (for example `http://192.168.10.15:3000/namespace/awesome-project`). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_REF_PATH` | 11.6 | all | The ref path of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). (for example `refs/merge-requests/1/head`). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` | 11.6 | all | The source branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_ID` | 11.6 | all | The ID of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` | 11.6 | all | The path of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_URL` | 11.6 | all | The URL of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` | 11.6 | all | The target branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_TITLE` | 11.9 | all | The title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_EVENT_TYPE` | 12.3 | all | The event type of the merge request, if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Can be `detached`, `merged_result` or `merge_train`. |
| `CI_MERGE_REQUEST_DIFF_ID` | 13.7 | all | The version of the merge request diff, if [the pipelines are for merge requests](../merge_request_pipelines/index.md). |
| `CI_MERGE_REQUEST_DIFF_BASE_SHA` | 13.7 | all | The base SHA of the merge request diff, if [the pipelines are for merge requests](../merge_request_pipelines/index.md). |
| `CI_NODE_INDEX` | 11.5 | all | Index of the job in the job set. If the job is not parallelized, this variable is not set. |
| `CI_NODE_TOTAL` | 11.5 | all | Total number of instances of this job running in parallel. If the job is not parallelized, this variable is set to `1`. |
| `CI_PAGES_DOMAIN` | 11.8 | all | The configured domain that hosts GitLab Pages. |
| `CI_PAGES_URL` | 11.8 | all | URL to GitLab Pages-built pages. Always belongs to a subdomain of `CI_PAGES_DOMAIN`. |
| `CI_PIPELINE_ID` | 8.10 | all | The instance-level ID of the current pipeline. This is a unique ID across all projects on GitLab. |
| `CI_PIPELINE_IID` | 11.0 | all | The project-level IID (internal ID) of the current pipeline. This ID is unique for the current project. |
| `CI_PIPELINE_SOURCE` | 10.0 | all | Indicates how the pipeline was triggered. Possible options are: `push`, `web`, `schedule`, `api`, `external`, `chat`, `webide`, `merge_request_event`, `external_pull_request_event`, `parent_pipeline`, [`trigger`, or `pipeline`](../triggers/README.md#authentication-tokens). For pipelines created before GitLab 9.5, this is displayed as `unknown`. |
| `CI_PIPELINE_TRIGGERED` | all | all | The flag to indicate that job was [triggered](../triggers/README.md). |
| `CI_PIPELINE_URL` | 11.1 | 0.5 | Pipeline details URL. |
| `CI_PROJECT_CONFIG_PATH` | 13.8 | all | The CI configuration path for the project. |
| `CI_PROJECT_DIR` | all | all | The full path where the repository is cloned and where the job is run. If the GitLab Runner `builds_dir` parameter is set, this variable is set relative to the value of `builds_dir`. For more information, see [Advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) for GitLab Runner. |
| `CI_PROJECT_ID` | all | all | The unique ID of the current project that GitLab CI/CD uses internally. |
| `CI_PROJECT_NAME` | 8.10 | 0.5 | The name of the directory for the project that is being built. For example, if the project URL is `gitlab.example.com/group-name/project-1`, the `CI_PROJECT_NAME` would be `project-1`. |
| `CI_PROJECT_NAMESPACE` | 8.10 | 0.5 | The project namespace (username or group name) that is being built. |
| `CI_PROJECT_ROOT_NAMESPACE` | 13.2 | 0.5 | The **root** project namespace (username or group name) that is being built. For example, if `CI_PROJECT_NAMESPACE` is `root-group/child-group/grandchild-group`, `CI_PROJECT_ROOT_NAMESPACE` would be `root-group`. |
| `CI_PROJECT_PATH` | 8.10 | 0.5 | The namespace with project name. |
| `CI_PROJECT_PATH_SLUG` | 9.3 | all | `$CI_PROJECT_PATH` in lowercase and with everything except `0-9` and `a-z` replaced with `-`. Use in URLs and domain names. |
| `CI_PROJECT_REPOSITORY_LANGUAGES` | 12.3 | all | Comma-separated, lowercase list of the languages used in the repository (for example `ruby,javascript,html,css`). |
| `CI_PROJECT_TITLE` | 12.4 | all | The human-readable project name as displayed in the GitLab web interface. |
| `CI_PROJECT_URL` | 8.10 | 0.5 | The HTTP(S) address to access project. |
| `CI_PROJECT_VISIBILITY` | 10.3 | all | The project visibility (internal, private, public). |
| `CI_REGISTRY` | 8.10 | 0.5 | If the Container Registry is enabled it returns the address of the GitLab Container Registry. This variable includes a `:port` value if one has been specified in the registry configuration. |
| `CI_REGISTRY_IMAGE` | 8.10 | 0.5 | If the Container Registry is enabled for the project it returns the address of the registry tied to the specific project. |
| `CI_REGISTRY_PASSWORD` | 9.0 | all | The password to use to push containers to the GitLab Container Registry, for the current project. |
| `CI_REGISTRY_USER` | 9.0 | all | The username to use to push containers to the GitLab Container Registry, for the current project. |
| `CI_REPOSITORY_URL` | 9.0 | all | The URL to clone the Git repository. |
| `CI_RUNNER_DESCRIPTION` | 8.10 | 0.5 | The description of the runner as saved in GitLab. |
| `CI_RUNNER_EXECUTABLE_ARCH` | all | 10.6 | The OS/architecture of the GitLab Runner executable (note that this is not necessarily the same as the environment of the executor). |
| `CI_RUNNER_ID` | 8.10 | 0.5 | The unique ID of runner being used. |
| `CI_RUNNER_REVISION` | all | 10.6 | GitLab Runner revision that is executing the current job. |
| `CI_RUNNER_SHORT_TOKEN` | all | 12.3 | First eight characters of the runner's token used to authenticate new job requests. Used as the runner's unique ID. |
| `CI_RUNNER_TAGS` | 8.10 | 0.5 | The defined runner tags. |
| `CI_RUNNER_VERSION` | all | 10.6 | GitLab Runner version that is executing the current job. |
| `CI_SERVER` | all | all | Mark that job is executed in CI environment. |
| `CI_SERVER_URL` | 12.7 | all | The base URL of the GitLab instance, including protocol and port (like `https://gitlab.example.com:8080`). |
| `CI_SERVER_HOST` | 12.1 | all | Host component of the GitLab instance URL, without protocol and port (like `gitlab.example.com`). |
| `CI_SERVER_PORT` | 12.8 | all | Port component of the GitLab instance URL, without host and protocol (like `3000`). |
| `CI_SERVER_PROTOCOL` | 12.8 | all | Protocol component of the GitLab instance URL, without host and port (like `https`). |
| `CI_SERVER_NAME` | all | all | The name of CI server that is used to coordinate jobs. |
| `CI_SERVER_REVISION` | all | all | GitLab revision that is used to schedule jobs. |
| `CI_SERVER_VERSION` | all | all | GitLab version that is used to schedule jobs. |
| `CI_SERVER_VERSION_MAJOR` | 11.4 | all | GitLab version major component. |
| `CI_SERVER_VERSION_MINOR` | 11.4 | all | GitLab version minor component. |
| `CI_SERVER_VERSION_PATCH` | 11.4 | all | GitLab version patch component. |
| `CI_SHARED_ENVIRONMENT` | all | 10.1 | Marks that the job is executed in a shared environment (something that is persisted across CI invocations like `shell` or `ssh` executor). If the environment is shared, it is set to true, otherwise it is not defined at all. |
| `GITLAB_CI` | all | all | Mark that job is executed in GitLab CI/CD environment. |
| `GITLAB_FEATURES` | 10.6 | all | The comma separated list of licensed features available for your instance and plan. |
| `GITLAB_USER_EMAIL` | 8.12 | all | The email of the user who started the job. |
| `GITLAB_USER_ID` | 8.12 | all | The ID of the user who started the job. |
| `GITLAB_USER_LOGIN` | 10.0 | all | The login username of the user who started the job. |
| `GITLAB_USER_NAME` | 10.0 | all | The real name of the user who started the job. |
| `TRIGGER_PAYLOAD` | 13.9 | all | This variable is available when a pipeline is [triggered with a webhook](../triggers/README.md#using-webhook-payload-in-the-triggered-pipeline) |
| `CI_EXTERNAL_PULL_REQUEST_IID` | 12.3 | all | Pull request ID from GitHub. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_REPOSITORY` | 13.3 | all | The source repository name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_REPOSITORY` | 13.3 | all | The target repository name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_NAME` | 12.3 | all | The source branch name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHA` | 12.3 | all | The HEAD SHA of the source branch of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAME` | 12.3 | all | The target branch name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHA` | 12.3 | all | The HEAD SHA of the target branch of the pull request. |

4
doc/ci/yaml/script.md
View File

@ -121,10 +121,10 @@ job:
- echo -e "\e[31mThis text is red,\e[0m but this text isn't\e[31m however this text is red again."
```
You can define the color codes in Shell variables, or even [custom CI/CD variables](../variables/README.md#custom-cicd-variables),
You can define the color codes in Shell environment variables, or even [custom CI/CD variables](../variables/README.md#custom-cicd-variables),
which makes the commands easier to read and reusable.
For example, using the same example as above and variables defined in a `before_script`:
For example, using the same example as above and environment variables defined in a `before_script`:
```yaml
job:

4
doc/development/build_test_package.md
View File

@ -40,7 +40,7 @@ used to trigger the build.
In scenarios where a configuration change is to be introduced and Omnibus GitLab
repository already has the necessary changes in a specific branch, you can build
a package against that branch through an environment variable named
`OMNIBUS_BRANCH`. To do this, specify that environment variable with the name of
a package against that branch through a CI/CD variable named
`OMNIBUS_BRANCH`. To do this, specify that variable with the name of
the branch as value in `.gitlab-ci.yml` and push a commit. This will create a
manual job that can be used to trigger the build.

4
doc/development/cicd/templates.md
View File

@ -47,7 +47,7 @@ performance:
```
and users include this template with passing an argument to the `performance` job.
This can be done by specifying the environment variable `TARGET_URL` in _their_ `.gitlab-ci.yml`:
This can be done by specifying the CI/CD variable `TARGET_URL` in _their_ `.gitlab-ci.yml`:
```yaml
include:
@ -180,7 +180,7 @@ is updated in a major version GitLab release.
## Security
A template could contain malicious code. For example, a template that contains the `export` shell command in a job
might accidentally expose project secret variables in a job log.
might accidentally expose secret project CI/CD variables in a job log.
If you're unsure if it's secure or not, you need to ask security experts for cross-validation.
## Contribute CI/CD Template Merge Requests

2
doc/development/documentation/site_architecture/release_process.md
View File

@ -183,7 +183,7 @@ the [`compile_dev` job](https://gitlab.com/gitlab-org/gitlab-docs/-/jobs/3280424
the `master` branches were pulled.
To fix this, re-run the pipeline (`https://gitlab.com/gitlab-org/gitlab-docs/pipelines/new`)
for the `update-12-2-for-release-12-4` branch, by including the following environment variables:
for the `update-12-2-for-release-12-4` branch, by including the following CI/CD variables:
- `BRANCH_CE` set to `12-2-stable`
- `BRANCH_EE` set to `12-2-stable-ee`

22
doc/development/integrations/secure.md
View File

@ -89,7 +89,7 @@ it's declared under the `reports:sast` key in the job definition, not because of
### Policies
Certain GitLab workflows, such as [AutoDevOps](../../topics/autodevops/customize.md#disable-jobs),
define variables to indicate that given scans should be disabled. You can check for this by looking
define CI/CD variables to indicate that given scans should be disabled. You can check for this by looking
for variables such as `DEPENDENCY_SCANNING_DISABLED`, `CONTAINER_SCANNING_DISABLED`,
`SAST_DISABLED`, and `DAST_DISABLED`. If appropriate based on the scanner type, you should then
disable running the custom scanner.
@ -97,7 +97,7 @@ disable running the custom scanner.
GitLab also defines a `CI_PROJECT_REPOSITORY_LANGUAGES` variable, which provides the list of
languages in the repository. Depending on this value, your scanner may or may not do something different.
Language detection currently relies on the [`linguist`](https://github.com/github/linguist) Ruby gem.
See [GitLab CI/CD predefined variables](../../ci/variables/predefined_variables.md).
See the [predefined CI/CD variables](../../ci/variables/predefined_variables.md).
#### Policy checking example
@ -170,23 +170,23 @@ It also generates text output on the standard output and standard error streams,
### Variables
All CI variables are passed to the scanner as environment variables.
The scanned project is described by the [predefined CI variables](../../ci/variables/README.md).
All CI/CD variables are passed to the scanner as environment variables.
The scanned project is described by the [predefined CI/CD variables](../../ci/variables/README.md).
#### SAST and Dependency Scanning
SAST and Dependency Scanning scanners must scan the files in the project directory, given by the `CI_PROJECT_DIR` variable.
SAST and Dependency Scanning scanners must scan the files in the project directory, given by the `CI_PROJECT_DIR` CI/CD variable.
#### Container Scanning
In order to be consistent with the official Container Scanning for GitLab,
scanners must scan the Docker image whose name and tag are given by
`CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG`, respectively. If the `DOCKER_IMAGE`
variable is provided, then the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables
CI/CD variable is provided, then the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables
are ignored, and the image specified in the `DOCKER_IMAGE` variable is scanned instead.
If not provided, `CI_APPLICATION_REPOSITORY` should default to
`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`, which is a combination of predefined CI variables.
`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`, which is a combination of predefined CI/CD variables.
`CI_APPLICATION_TAG` should default to `CI_COMMIT_SHA`.
The scanner should sign in the Docker registry
@ -197,13 +197,13 @@ If these are not defined, then the scanner should use
#### Configuration files
While scanners may use `CI_PROJECT_DIR` to load specific configuration files,
it is recommended to expose configuration as environment variables, not files.
it is recommended to expose configuration as CI/CD variables, not files.
### Output file
Like any artifact uploaded to the GitLab CI/CD,
Like any artifact uploaded to GitLab CI/CD,
the Secure report generated by the scanner must be written in the project directory,
given by the `CI_PROJECT_DIR` environment variable.
given by the `CI_PROJECT_DIR` CI/CD variable.
It is recommended to name the output file after the type of scanning, and to use `gl-` as a prefix.
Since all Secure reports are JSON files, it is recommended to use `.json` as a file extension.
@ -242,7 +242,7 @@ Also, we recommend prefixing error messages with `[ERRO]`, warnings with `[WARN]
#### Logging level
The scanner should filter out a log message if its log level is lower than the
one set in the `SECURE_LOG_LEVEL` variable. For instance, `info` and `warn`
one set in the `SECURE_LOG_LEVEL` CI/CD variable. For instance, `info` and `warn`
messages should be skipped when `SECURE_LOG_LEVEL` is set to `error`. Accepted
values are as follows, listed from highest to lowest:

2
doc/development/multi_version_compatibility.md
View File

@ -207,7 +207,7 @@ variable `CI_NODE_TOTAL` being an integer failed. This was caused because after
1. Old code: Runners requested a job from an API node that is running the previous version.
1. As a result, the [new code](https://gitlab.com/gitlab-org/gitlab/blob/42b82a9a3ac5a96f9152aad6cbc583c42b9fb082/app/models/concerns/ci/contextable.rb#L104)
was not run on the API server. The runner's request failed because the
older API server tried return the `CI_NODE_TOTAL` CI variable, but
older API server tried return the `CI_NODE_TOTAL` CI/CD variable, but
instead of sending an integer value (e.g. 9), it sent a serialized
`Hash` value (`{:number=>9, :total=>9}`).

17
doc/development/pipelines.md
View File

@ -29,7 +29,7 @@ Pipelines are always created for the following scenarios:
- Tags.
- Stable, `auto-deploy`, and security branches.
Pipeline creation is also affected by the following CI variables:
Pipeline creation is also affected by the following CI/CD variables:
- If `$FORCE_GITLAB_CI` is set, pipelines are created.
- If `$GITLAB_INTERNAL` is not set, pipelines are not created.
@ -414,10 +414,10 @@ The `rspec fail-fast` is a no-op if there are more than 10 test files related to
Merge Request. This prevents `rspec fail-fast` duration from exceeding the average
`rspec` job duration and defeating its purpose.
This number can be overridden by setting a CI variable named `RSPEC_FAIL_FAST_TEST_FILE_COUNT_THRESHOLD`.
This number can be overridden by setting a CI/CD variable named `RSPEC_FAIL_FAST_TEST_FILE_COUNT_THRESHOLD`.
NOTE:
This experiment is only enabled when the CI variable `RSPEC_FAIL_FAST_ENABLED=true` is set.
This experiment is only enabled when the CI/CD variable `RSPEC_FAIL_FAST_ENABLED=true` is set.
#### Determining related test files in a Merge Request
@ -531,8 +531,7 @@ several reasons:
The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
[defined by GitLab.com shared runners](../user/gitlab_com/index.md#pre-clone-script).
The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD
variable:
The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD variable:
```shell
echo "Downloading archived master..."
@ -638,7 +637,7 @@ Some of the jobs are using images from Docker Hub, where we also use
`${GITLAB_DEPENDENCY_PROXY}` as a prefix to the image path, so that we pull
images from our [Dependency Proxy](../user/packages/dependency_proxy/index.md).
`${GITLAB_DEPENDENCY_PROXY}` is a group variable defined in
`${GITLAB_DEPENDENCY_PROXY}` is a group CI/CD variable defined in
[`gitlab-org`](https://gitlab.com/gitlab-org) as
`${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/`. This means when we use an image
defined as:
@ -653,7 +652,7 @@ Docker Hub unless `${GITLAB_DEPENDENCY_PROXY}` is also defined there.
### Default variables
In addition to the [predefined variables](../ci/variables/predefined_variables.md),
In addition to the [predefined CI/CD variables](../ci/variables/predefined_variables.md),
each pipeline includes default variables defined in
[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
@ -679,7 +678,7 @@ that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-key
| `.use-pg12` | Allows a job to use the `postgres:12` and `redis:4.0-alpine` services. |
| `.use-pg12-ee` | Same as `.use-pg12` but also use the `docker.elastic.co/elasticsearch/elasticsearch:7.9.2` services. |
| `.use-kaniko` | Allows a job to use the `kaniko` tool to build Docker images. |
| `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` environment variable. |
| `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` CI/CD variable. |
| `.use-docker-in-docker` | Allows a job to use Docker in Docker. |
### `rules`, `if:` conditions and `changes:` patterns
@ -726,7 +725,7 @@ and included in `rules` definitions via [YAML anchors](../ci/yaml/README.md#anch
| `if-dot-com-gitlab-org-and-security-tag` | Limit jobs creation to tags for the `gitlab-org` and `gitlab-org/security` groups on GitLab.com. | |
| `if-dot-com-ee-schedule` | Limits jobs to scheduled pipelines for the `gitlab-org/gitlab` project on GitLab.com. | |
| `if-cache-credentials-schedule` | Limits jobs to scheduled pipelines with the `$CI_REPO_CACHE_CREDENTIALS` variable set. | |
| `if-rspec-fail-fast-disabled` | Limits jobs to pipelines with `$RSPEC_FAIL_FAST_ENABLED` variable not set to `"true"`. | |
| `if-rspec-fail-fast-disabled` | Limits jobs to pipelines with `$RSPEC_FAIL_FAST_ENABLED` CI/CD variable not set to `"true"`. | |
| `if-rspec-fail-fast-skipped` | Matches if the pipeline is for a merge request and the MR title includes "SKIP RSPEC FAIL-FAST". | |
| `if-security-pipeline-merge-result` | Matches if the pipeline is for a security merge request triggered by `@gitlab-release-tools-bot`. | |

2
doc/development/testing_guide/end_to_end/environment_selection.md
View File

@ -58,7 +58,7 @@ end
If the test has a `before` or `after`, you must add the `only` metadata
to the outer `RSpec.describe`.
If you want to run an `only: { :pipeline }` tagged test on your local GDK make sure either the `CI_PROJECT_NAME` environment variable is unset, or that the `CI_PROJECT_NAME` environment variable matches the specified pipeline in the `only: { :pipeline }` tag, or just delete the `only: { :pipeline }` tag.
If you want to run an `only: { :pipeline }` tagged test on your local GDK make sure either the `CI_PROJECT_NAME` CI/CD variable is unset, or that the `CI_PROJECT_NAME` variable matches the specified pipeline in the `only: { :pipeline }` tag, or just delete the `only: { :pipeline }` tag.
## Quarantining a test for a specific environment

2
doc/operations/metrics/dashboards/variables.md
View File

@ -16,7 +16,7 @@ Queries that continue to use the old format display no data.
## Predefined variables
GitLab supports a limited set of [CI variables](../../../ci/variables/README.md)
GitLab supports a limited set of [CI/CD variables](../../../ci/variables/README.md)
in the Prometheus query. This is particularly useful for identifying a specific
environment, for example with `ci_environment_slug`. Variables for Prometheus queries
must be lowercase. The supported variables are:

4
doc/operations/metrics/embed.md
View File

@ -4,10 +4,10 @@ group: Health
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Embedding metric charts within GitLab-flavored Markdown **(FREE)**
# Embedding metric charts within GitLab Flavored Markdown **(FREE)**
You can display metrics charts within
[GitLab Flavored Markdown](../../user/markdown.md#gitlab-flavored-markdown-gfm)
[GitLab Flavored Markdown](../../user/markdown.md#gitlab-flavored-markdown)
fields such as issue or merge request descriptions. The maximum number of embedded
charts allowed in a GitLab Flavored Markdown field is 100.
Embedding charts is useful when sharing an application incident or performance

2
doc/ssh/README.md
View File

@ -188,7 +188,7 @@ To use SSH with GitLab, copy your public key to your GitLab account.
**macOS:**
```shell
pbcopy < ~/.ssh/id_ed25519.pub
tr -d '\n' < ~/.ssh/id_ed25519.pub | pbcopy
```
**Linux** (requires the `xclip` package):

2
doc/topics/autodevops/troubleshooting.md
View File

@ -92,7 +92,7 @@ If you receive this error, you can do one of the following actions:
`POSTGRES_ENABLED` to `false` and re-deploy. This option is especially relevant to
users of *custom charts without the in-chart PostgreSQL dependency*.
Database auto-detection is based on the `postgresql.enabled` Helm value for
your release. This value is set based on the `POSTGRES_ENABLED` CI variable
your release. This value is set based on the `POSTGRES_ENABLED` CI/CD variable
and persisted by Helm, regardless of whether or not your chart uses the
variable.

4
doc/user/admin_area/settings/instance_template_repository.md
View File

@ -5,9 +5,9 @@ info: "To determine the technical writer assigned to the Stage/Group associated
type: reference
---
# Instance template repository **(PREMIUM SELF)** **(FREE)**
# Instance template repository **(PREMIUM SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5986) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.3.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5986) in GitLab Premium 11.3.
In hosted systems, enterprises often have a need to share their own templates
across teams. This feature allows an administrator to pick a project to be the

2
doc/user/group/epics/index.md
View File

@ -154,7 +154,7 @@ You can also consult the [group permissions table](../../permissions.md#group-me
- Comments: collaborate on that epic by posting comments in its thread.
These text fields also fully support
[GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
[GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown).
## Comment or start a thread

5
doc/user/group/index.md
View File

@ -57,11 +57,12 @@ To create a group:
- To the left of the search box, select the plus sign and then **New group**.
1. For the **Group name**, use only:
- Alphanumeric characters
- Emojis
- Underscores
- Dashes and dots
- Spaces
- Dashes, dots, spaces and parenthesis (however, it cannot start with any of these characters)
For a list of words that cannot be used as group names, see [reserved names](../reserved_names.md).
1. For the **Group URL**, which is used for the [namespace](#namespaces),
use only:
- Alphanumeric characters

40
doc/user/markdown.md
View File

@ -18,13 +18,13 @@ for a complete Kramdown reference.
NOTE:
We encourage you to view this document as [rendered by GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md).
## GitLab Flavored Markdown (GFM)
## GitLab Flavored Markdown
GitLab uses "GitLab Flavored Markdown" (GFM). It extends the [CommonMark specification](https://spec.commonmark.org/current/)
GitLab uses "GitLab Flavored Markdown". It extends the [CommonMark specification](https://spec.commonmark.org/current/)
(which is based on standard Markdown) in several ways to add more features.
It was inspired by [GitHub Flavored Markdown](https://docs.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).
You can use GFM in the following areas:
You can use GitLab Flavored Markdown in the following areas:
- Comments
- Issues
@ -92,12 +92,12 @@ if any changes are needed.
`diff_redcarpet_cmark` is not an officially supported product.
### GFM extends standard Markdown
### GitLab Flavored Markdown extends standard Markdown
GitLab makes full use of the standard (CommonMark) formatting, but also includes more
helpful features for GitLab users.
It makes use of [new Markdown features](#new-gfm-markdown-extensions),
It makes use of [new Markdown features](#new-gitlab-flavored-markdown-extensions),
not found in standard Markdown:
- [Color chips written in HEX, RGB or HSL](#colors)
@ -124,7 +124,7 @@ changing how standard Markdown is used:
| [line breaks](#line-breaks) | [more line break control](#newlines) |
| [links](#links) | [automatically linking URLs](#url-auto-linking) |
## New GFM Markdown extensions
## New GitLab Flavored Markdown extensions
### Colors
@ -251,7 +251,7 @@ If this section isn't rendered correctly, [view it in GitLab](https://gitlab.com
```markdown
Sometimes you want to :monkey: around a bit and add some :star2: to your :speech_balloon:. Well we have a gift for you:
:zap: You can use emoji anywhere GFM is supported. :v:
:zap: You can use emoji anywhere GitLab Flavored Markdown is supported. :v:
You can use it to point out a :bug: or warn about :speak_no_evil: patches. And if someone improves your really :snail: code, send them some :birthday:. People :heart: you for that.
@ -262,7 +262,7 @@ Consult the [Emoji Cheat Sheet](https://www.emojicopy.com) for a list of all sup
Sometimes you want to <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/monkey.png" width="20px" height="20px" style="display:inline;margin:0;border: 0"> around a bit and add some <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/star2.png" width="20px" height="20px" style="display:inline;margin:0;border: 0"> to your <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/speech_balloon.png" width="20px" height="20px" style="display:inline;margin:0;border: 0">. Well we have a gift for you:
<img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/zap.png" width="20px" height="20px" style="display:inline;margin:0;border: 0">You can use emoji anywhere GFM is supported. <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/v.png" width="20px" height="20px" style="display:inline;margin:0;border: 0">
<img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/zap.png" width="20px" height="20px" style="display:inline;margin:0;border: 0">You can use emoji anywhere GitLab Flavored Markdown is supported. <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/v.png" width="20px" height="20px" style="display:inline;margin:0;border: 0">
You can use it to point out a<img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/bug.png" width="20px" height="20px" style="display:inline;margin:0;border: 0"> or warn about <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/speak_no_evil.png" width="20px" height="20px" style="display:inline;margin:0;border: 0"> patches. If someone improves your really <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/snail.png" width="20px" height="20px" style="display:inline;margin:0;border: 0"> code, send them some <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/birthday.png" width="20px" height="20px" style="display:inline;margin:0;border: 0">. People <img src="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/heart.png" width="20px" height="20px" style="display:inline;margin:0;border: 0"> you for that.
@ -424,14 +424,14 @@ the [Asciidoctor user manual](https://asciidoctor.org/docs/user-manual/#activati
### Special GitLab references
GFM recognizes special GitLab related references. For example, you can reference
an issue, a commit, a team member, or even an entire project team. GFM turns
GitLab Flavored Markdown recognizes special GitLab related references. For example, you can reference
an issue, a commit, a team member, or even an entire project team. GitLab Flavored Markdown turns
that reference into a link so you can navigate between them.
Additionally, GFM recognizes certain cross-project references and also has a shorthand
Additionally, GitLab Flavored Markdown recognizes certain cross-project references and also has a shorthand
version to reference other projects from the same namespace.
GFM recognizes the following:
GitLab Flavored Markdown recognizes the following:
| references | input | cross-project reference | shortcut inside same namespace |
| :------------------------------ | :------------------------- | :-------------------------------------- | :----------------------------- |
@ -630,7 +630,7 @@ Quote break.
If this section isn't rendered correctly, [view it in GitLab](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#multiline-blockquote).
GFM extends the standard Markdown by also supporting multi-line blockquotes
GitLab Flavored Markdown extends the standard Markdown by also supporting multi-line blockquotes
fenced by `>>>`:
```markdown
@ -778,7 +778,7 @@ But let's throw in a <b>tag</b>.
There are multiple ways to emphasize text in Markdown. You can italicize, bold, strikethrough,
and combine these emphasis styles together.
Strikethrough is not part of the core Markdown standard, but is part of GFM.
Strikethrough is not part of the core Markdown standard, but is part of GitLab Flavored Markdown.
Examples:
@ -807,7 +807,7 @@ If this section isn't rendered correctly,
Avoid italicizing a portion of a word, especially when you're
dealing with code and names that often appear with multiple underscores.
GFM extends the standard Markdown standard by ignoring multiple underlines in words,
GitLab Flavored Markdown extends the standard Markdown standard by ignoring multiple underlines in words,
to allow better rendering of Markdown documents discussing code:
```markdown
@ -899,7 +899,7 @@ Alt-H2
#### Header IDs and links
GFM extends the standard Markdown standard so that all Markdown-rendered headers automatically
GitLab Flavored Markdown extends the standard Markdown standard so that all Markdown-rendered headers automatically
get IDs, which can be linked to, except in comments.
On hover, a link to those IDs becomes visible to make it easier to copy the link to
@ -1193,7 +1193,7 @@ in the *same paragraph*.
#### Newlines
GFM adheres to the Markdown specification in how [paragraphs and line breaks are handled](https://spec.commonmark.org/current/).
GitLab Flavored Markdown adheres to the Markdown specification in how [paragraphs and line breaks are handled](https://spec.commonmark.org/current/).
A paragraph is one or more consecutive lines of text, separated by one or
more blank lines (two newlines at the end of the first paragraph), as [explained above](#line-breaks).
@ -1275,7 +1275,7 @@ points the link to `wikis/style` only when the link is inside of a wiki Markdown
#### URL auto-linking
GFM auto-links almost any URL you put into your text:
GitLab Flavored Markdown auto-links almost any URL you put into your text:
```markdown
- https://www.google.com
@ -1418,7 +1418,7 @@ Example:
### Superscripts / Subscripts
CommonMark and GFM don't support the Redcarpet superscript syntax ( `x^2` ).
CommonMark and GitLab Flavored Markdown don't support the Redcarpet superscript syntax ( `x^2` ).
Use the standard HTML syntax for superscripts and subscripts:
```html
@ -1435,7 +1435,7 @@ while the equation for the theory of relativity is E = mc<sup>2</sup>.
### Tables
Tables are not part of the core Markdown spec, but they are part of GFM.
Tables are not part of the core Markdown spec, but they are part of GitLab Flavored Markdown.
1. The first line contains the headers, separated by "pipes" (`|`).
1. The second line separates the headers from the cells, and must contain three or more dashes.

2
doc/user/project/deploy_boards.md
View File

@ -94,7 +94,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
1. Ensure Kubernetes annotations of `app.gitlab.com/env: $CI_ENVIRONMENT_SLUG`
and `app.gitlab.com/app: $CI_PROJECT_PATH_SLUG` are applied to the
deployments, replica sets, and pods, where `$CI_ENVIRONMENT_SLUG` and
`$CI_PROJECT_PATH_SLUG` are the values of the CI variables. This is so we can
`$CI_PROJECT_PATH_SLUG` are the values of the CI/CD variables. This is so we can
lookup the proper environment in a cluster/namespace which may have more
than one. These resources should be contained in the namespace defined in
the Kubernetes service setting. You can use an [Auto deploy](../../topics/autodevops/stages.md#auto-deploy) `.gitlab-ci.yml`

BIN
doc/user/project/integrations/img/mattermost_console_integrations.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 112 KiB

BIN
doc/user/project/integrations/img/mattermost_goto_console.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.6 KiB

BIN
doc/user/project/integrations/img/mattermost_slash_command_token.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 8.4 KiB

BIN
doc/user/project/integrations/img/mattermost_team_integrations.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.6 KiB

151
doc/user/project/integrations/mattermost_slash_commands.md
View File

@ -6,116 +6,119 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Mattermost slash commands **(FREE)**
> Introduced in GitLab 8.14
If your team uses [Mattermost](https://mattermost.com/) as a chat service, you can
integrate GitLab commands into Mattermost chat. This integration enables users to
run common operations, such as creating a GitLab issue, from the Mattermost chat
environment.
Mattermost commands give users an extra interface to perform common operations
from the chat environment. This allows one to, for example, create an issue as
soon as the idea was discussed in Mattermost.
GitLab can also send events (e.g., `issue created`) to Mattermost as notifications.
This is the separately configured [Mattermost Notifications Service](mattermost.md).
GitLab can also send events (such as `issue created`) to Mattermost as part of the
separately configured [Mattermost Notifications Service](mattermost.md).
## Prerequisites
Mattermost 3.4 and up is required.
Mattermost [3.4 or later](https://mattermost.com/blog/category/releases/) is required.
GitLab provides different methods of configuring Mattermost slash commands, depending
on your configuration:
If you have the Omnibus GitLab package installed, Mattermost is already bundled
in it. All you have to do is configure it. Read more in the
[Omnibus GitLab Mattermost documentation](https://docs.gitlab.com/omnibus/gitlab-mattermost/).
- **Omnibus GitLab installations**: Mattermost is bundled with
[Omnibus GitLab](https://docs.gitlab.com/omnibus/). To configure Mattermost for Omnibus GitLab, read the
[Omnibus GitLab Mattermost documentation](https://docs.gitlab.com/omnibus/gitlab-mattermost/).
- **If Mattermost is installed on the same server as GitLab**, use the
[automated configuration](#automated-configuration).
- **For all other installations**, use the [manual configuration](#manual-configuration).
## Automated configuration
If Mattermost is installed on the same server as GitLab, the configuration process can be
done for you by GitLab.
Go to the Mattermost Slash Command service on your project and click the 'Add to Mattermost' button.
Go to the Mattermost Slash Command service on your project and click **Add to Mattermost** button.
## Manual configuration
The configuration consists of two parts. First you need to enable the slash
commands in Mattermost and then enable the service in GitLab.
To manually configure slash commands in Mattermost, you must:
### Step 1. Enable custom slash commands in Mattermost
1. [Enable custom slash commands](#enable-custom-slash-commands) in Mattermost.
1. [Get configuration values](#get-configuration-values-from-gitlab) from GitLab.
1. [Create a new slash command](#create-a-slash-command) in Mattermost.
1. [Provide the Mattermost token](#provide-the-mattermost-token-to-gitlab) to GitLab.
This step is only required when using a source install. Omnibus installs are
preconfigured with the right settings.
### Enable custom slash commands
The first thing to do in Mattermost is to enable custom slash commands from
the administrator console.
NOTE:
Omnibus GitLab installations are preconfigured. This step is required only for
installations from source.
1. Log in with an account that has administrator privileges and navigate to the system
console.
To enable custom slash commands from the Mattermost administrator console:
![Mattermost go to console](img/mattermost_goto_console.png)
1. Sign in to Mattermost as a user with administrator privileges.
1. Next to your username, click the **{ellipsis_v}** **Settings** icon, and
select **System Console**.
1. Select **Integration Management**, and set these values to `TRUE`:
- **Enable Custom Slash Commands**
- **Enable integrations to override usernames**
- **Enable integrations to override profile picture icons**
1. Click **Save**, but do not close this browser tab, because you need it in
a later step.
1. Click **Integration Management** and set **Enable Custom Slash Commands**,
**Enable integrations to override usernames**, and **Enable
integrations to override profile picture icons** to true
### Get configuration values from GitLab
![Mattermost console](img/mattermost_console_integrations.png)
After you enable custom slash commands in Mattermost, you need configuration
information from GitLab. To get this information:
1. Click **Save** at the bottom to save the changes.
1. In a different browser tab than your current Mattermost session, sign in to
GitLab as a user with [administrator permissions](../../permissions.md).
1. In the top navigation bar, go to **{admin}** **Admin Area**.
1. In the left menu, go to **Settings > Integrations** and select
**Mattermost slash commands**.
1. GitLab displays potential values for Mattermost settings. Copy the **Request URL**
as you need it for the next step. All other values are suggestions.
1. Do not close this browser tab, because you need it in future steps.
### Step 2. Open the Mattermost slash commands service in GitLab
Next, create a slash command in Mattermost with the values from GitLab.
1. Open a new tab for GitLab, go to your project's
[Integrations page](overview.md#accessing-integrations)
and select the **Mattermost command** service to configure it.
A screen appears with all the values you need to copy in Mattermost as
described in the next step. Leave the window open.
### Create a slash command
NOTE:
GitLab offers some values for the Mattermost settings. Only **Request URL** is required
as offered, all the others are just suggestions.
To create a slash command, you need the values you obtained from GitLab in
the previous step:
![Mattermost setup instructions](img/mattermost_config_help.png)
1. Proceed to the next step and create a slash command in Mattermost with the
above values.
### Step 3. Create a new custom slash command in Mattermost
Now that you have enabled custom slash commands in Mattermost and opened
the Mattermost slash commands service in GitLab, it's time to copy these values
in a new slash command.
1. Back to Mattermost, under your team page settings, you should see the
**Integrations** option.
![Mattermost team integrations](img/mattermost_team_integrations.png)
1. Go to the **Slash Commands** integration and add a new one by clicking the
**Add Slash Command** button.
1. In the Mattermost tab you left open when you
[enabled custom slash commands](#enable-custom-slash-commands), go to your
team page.
1. Click the **{ellipsis_v}** **Settings** icon, and select **Integrations**.
1. In the left menu, select **Slash commands**.
1. Click **Add Slash Command**:
![Mattermost add command](img/mattermost_add_slash_command.png)
1. Provide a **Display Name** and **Description** for your new command.
1. Provide a **Command Trigger Word** according to your application's configuration:
1. Fill in the options for the custom command as described in
[step 2](#step-2-open-the-mattermost-slash-commands-service-in-gitlab).
- **If you intend to only connect one project to your Mattermost team**: Use
`/gitlab` for your trigger word.
- **If you intend to connect multiple projects**: Use a trigger word that relates
to your project, such as `/project-name` or `/gitlab-project-name`.
1. For **Request URL**, provide the value you copied from GitLab when you
[viewed configuration values](#get-configuration-values-from-gitlab).
1. For all other values, you may use the suggestions from GitLab or use your
preferred values.
1. Copy the **Token** value, as you need it in a later step, and click **Done**.
NOTE:
If you plan on connecting multiple projects, pick a slash command trigger
word that relates to your projects such as `/gitlab-project-name` or even
just `/project-name`. Only use `/gitlab` if you plan to only connect a single
project to your Mattermost team.
### Provide the Mattermost token to GitLab
![Mattermost add command configuration](img/mattermost_slash_command_configuration.png)
When you create a new slash command in Mattermost, it generates a token you must
provide to GitLab:
1. After you set up all the values, copy the token (we use it below) and
click **Done**.
![Mattermost slash command token](img/mattermost_slash_command_token.png)
### Step 4. Copy the Mattermost token into the Mattermost slash command service
1. In GitLab, paste the Mattermost token you copied in the previous step and
1. In the GitLab browser tab from
[getting configuration values from GitLab](#get-configuration-values-from-gitlab),
select the **Active** check box to enable this configuration.
1. In the **Token** field, paste the token you obtained from Mattermost.
ensure that the **Active** toggle is enabled.
![Mattermost copy token to GitLab](img/mattermost_gitlab_token.png)
1. Click **Save changes** for the changes to take effect.
You are now set to start using slash commands in Mattermost that talk to the
GitLab project you configured.
Your slash command can now communicate with your GitLab project.
## Authorizing Mattermost to interact with GitLab
@ -132,7 +135,7 @@ GitLab using the Mattermost commands.
## Available slash commands
The available slash commands are:
The available slash commands for Mattermost are:
| Command | Description | Example |
| ------- | ----------- | ------- |
@ -152,7 +155,7 @@ the [permissions you have on the project](../../permissions.md#project-members-p
## Troubleshooting
If an event is not being triggered, confirm that the channel you're using is a public one, as
If an event is not being triggered, confirm that the channel you're using is a public one.
Mattermost webhooks do not have access to private channels.
If a private channel is required, you can edit the webhook's channel in Mattermost and

6
doc/user/project/issues/issue_data_and_actions.md
View File

@ -186,7 +186,7 @@ This icon is only displayed if the user has permission to edit the issue.
### Description
The plain text title and description of the issue fill the top center of the issue page.
The description fully supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm),
The description fully supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown),
allowing many formatting options.
[In GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/10103) and later, changes to an
@ -281,7 +281,7 @@ or newest items to be shown first.
### Comments
Collaborate in the issue by posting comments in its thread. This text field also fully
supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown).
### Submit comment, start a thread, or comment and close
@ -301,7 +301,7 @@ You can also close the issue from here, so you don't need to scroll to the top o
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31103) in GitLab 12.3.
You can attach and remove Zoom meetings to issues using the `/zoom` and `/remove_zoom` [quick actions](../quick_actions.md) as part of
[GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
[GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown).
Attaching a [Zoom](https://zoom.us) call an issue
results in a **Join Zoom meeting** button at the top of the issue, just under the header.

2
doc/user/project/requirements/index.md
View File

@ -183,7 +183,7 @@ requirements_confirmation:
### Add the manual job to CI conditionally
To configure your CI to include the manual job only when there are some open
requirements, add a rule which checks `CI_HAS_OPEN_REQUIREMENTS` CI variable.
requirements, add a rule which checks `CI_HAS_OPEN_REQUIREMENTS` CI/CD variable.
```yaml
requirements_confirmation:

2
doc/user/project/settings/import_export.md
View File

@ -124,7 +124,7 @@ The following items will **not** be exported:
- Build traces and artifacts
- Container registry images
- CI variables
- CI/CD variables
- Webhooks
- Any encrypted tokens
- Merge Request Approvers

2
doc/user/project/web_ide/index.md
View File

@ -234,7 +234,7 @@ different branch.
When you edit Markdown files in the Web IDE, you can preview your changes by
clicking the **Preview Markdown** tab above the file editor. The Markdown preview
supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown).
You can also upload any local images by pasting them directly in the Markdown file.
The image is uploaded to the same directory and is named `image.png` by default.

2
lib/gitlab/background_migration/populate_uuids_for_security_findings.rb
View File

@ -10,7 +10,7 @@ module Gitlab
NOP_RELATION.new
end
def perform(_scan_ids); end
def perform(*_scan_ids); end
end
end
end

9
locale/gitlab.pot
View File

@ -20339,9 +20339,6 @@ msgstr ""
msgid "No issues found"
msgstr ""
msgid "No issues found for the selected labels"
msgstr ""
msgid "No iteration"
msgstr ""
@ -29817,6 +29814,9 @@ msgstr ""
msgid "There are no issues to show."
msgstr ""
msgid "There are no issues with the selected labels"
msgstr ""
msgid "There are no labels yet"
msgstr ""
@ -31485,6 +31485,9 @@ msgstr ""
msgid "Try changing or removing filters."
msgstr ""
msgid "Try grouping with different labels"
msgstr ""
msgid "Try to fork again"
msgstr ""

8
spec/controllers/search_controller_spec.rb
View File

@ -252,6 +252,14 @@ RSpec.describe SearchController do
get :count, params: { search: 'hello' }
end.to raise_error(ActionController::ParameterMissing)
end
it 'sets private cache control headers' do
get :count, params: { search: 'hello', scope: 'projects' }
expect(response).to have_gitlab_http_status(:ok)
expect(response.headers['Cache-Control']).to include('max-age=60, private')
end
end
describe 'GET #autocomplete' do

19
spec/finders/ci/daily_build_group_report_results_finder_spec.rb
View File

@ -79,6 +79,25 @@ RSpec.describe Ci::DailyBuildGroupReportResultsFinder do
])
end
end
context 'when provided dates are nil' do
let(:start_date) { nil }
let(:end_date) { nil }
let(:rspec_coverage_4) { create_daily_coverage('rspec', 98.0, 91.days.ago.to_date.to_s) }
it 'returns all coverages from the last 90 days' do
expect(coverages).to match_array(
[
karma_coverage_3,
rspec_coverage_3,
karma_coverage_2,
rspec_coverage_2,
karma_coverage_1,
rspec_coverage_1
]
)
end
end
end
end
end

6
spec/services/issues/create_service_spec.rb
View File

@ -286,6 +286,12 @@ RSpec.describe Issues::CreateService do
issue
end
it 'schedules a namespace onboarding create action worker' do
expect(Namespaces::OnboardingIssueCreatedWorker).to receive(:perform_async).with(project.namespace.id)
issue
end
end
context 'issue create service' do

28
spec/workers/namespaces/onboarding_issue_created_worker_spec.rb Normal file
View File

@ -0,0 +1,28 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe Namespaces::OnboardingIssueCreatedWorker, '#perform' do
let_it_be(:issue) { create(:issue) }
let(:namespace) { issue.namespace }
it_behaves_like 'records an onboarding progress action', :issue_created do
subject { described_class.new.perform(namespace.id) }
end
it_behaves_like 'does not record an onboarding progress action' do
subject { described_class.new.perform(nil) }
end
it_behaves_like 'an idempotent worker' do
let(:job_args) { [namespace.id] }
it 'sets the onboarding progress action' do
OnboardingProgress.onboard(namespace)
subject
expect(OnboardingProgress.completed?(namespace, :issue_created)).to eq(true)
end
end
end