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 2024-09-10 18:14:58 +00:00
parent fc56e587a7
commit 27e43e88d2
30 changed files with 458 additions and 418 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
.gitlab/ci/docs.gitlab-ci.yml
View File

@ -95,15 +95,19 @@ docs-lint links:
script:
- lychee --offline --no-progress --include-fragments doc
ui-docs-links lint:
extends:
- .docs:rules:docs-lint
- .static-analysis-base
- .ruby-cache
stage: lint
needs: []
script:
- bundle exec haml-lint -i DocumentationLinks
#
# Disabled while links are being cleaned up.
# See: https://gitlab.com/gitlab-org/gitlab/-/issues/419673
#
# ui-docs-links lint:
# extends:
# - .docs:rules:docs-lint
# - .static-analysis-base
# - .ruby-cache
# stage: lint
# needs: []
# script:
# - bundle exec haml-lint -i DocumentationLinks
docs-lint deprecations-and-removals:
variables:

8
app/assets/javascripts/lib/utils/datetime/date_calculation_utility.js
View File

@ -872,3 +872,11 @@ export function getMonthsBetweenDates(startDate, endDate) {
};
});
}
export function convertNanoToMs(nano) {
return nano / 1e6;
}
export function convertMsToNano(ms) {
return ms * 1e6;
}

4
app/assets/javascripts/observability/client.js
View File

@ -1,4 +1,4 @@
import { isValidDate } from '~/lib/utils/datetime_utility';
import { isValidDate, convertMsToNano } from '~/lib/utils/datetime_utility';
import * as Sentry from '~/sentry/sentry_browser_wrapper';
import axios from '~/lib/utils/axios_utils';
import { logError } from '~/lib/logger';
@ -205,7 +205,7 @@ const TRACING_FILTER_TO_QUERY_PARAM = {
status: 'status',
durationMs: (durationMs, operator, params) => {
const paramName = getFilterParamName('duration_nano', operator);
const durationNano = durationMs * 1e6; // converting ms to nano
const durationNano = convertMsToNano(durationMs);
if (paramName && durationNano) {
params.append(paramName, durationNano);
}

2
app/assets/javascripts/observability/utils.js
View File

@ -16,7 +16,7 @@ import {
* Return the data range for the given time period
* Accepted values are numbers followed by the unit 'm', 'h', 'd', e.g. '5m', '3h', '7d'
*
* e.g. timePerdio: '5m'
* e.g. timePeriod: '5m'
* returns: { min: Date(_now - 5min_), max: Date(_now_) }
*
* @param {String} timePeriod The 'period' string

9
config/feature_flags/wip/ai_settings_vue_admin.yml
View File

@ -1,9 +0,0 @@
---
name: ai_settings_vue_admin
feature_issue_url: https://gitlab.com/groups/gitlab-org/-/epics/13782
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/issues/470519
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/470584
milestone: '17.2'
group: group::ai framework
type: wip
default_enabled: false

2
doc/ci/pipelines/downstream_pipelines.md
View File

@ -721,7 +721,7 @@ Do not use this method to pass [masked variables](../variables/index.md#mask-a-c
to a multi-project pipeline. The CI/CD masking configuration is not passed to the
downstream pipeline and the variable could be unmasked in job logs in the downstream project.
You cannot use this method to forward [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables)
You cannot use this method to forward [job-only variables](../variables/predefined_variables.md#variable-availability)
to a downstream pipeline, as they are not available in trigger jobs.
Upstream pipelines take precedence over downstream ones. If there are two

9
doc/ci/pipelines/index.md
View File

@ -273,8 +273,9 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
You can trigger a pipeline in your project whenever a pipeline finishes for a new
tag in a different project.
You can set up your project to automatically trigger a pipeline based on tags in a different project.
When a new tag pipeline in the subscribed project finishes, it triggers a pipeline on your project's default branch,
regardless of the tag pipeline's success, failure, or cancellation.
Prerequisites:
@ -292,9 +293,7 @@ To trigger the pipeline when the upstream project is rebuilt:
For example, if the project is `https://gitlab.com/gitlab-org/gitlab`, use `gitlab-org/gitlab`.
1. Select **Subscribe**.
Any pipelines that complete successfully for new tags in the subscribed project
now trigger a pipeline on the current project's default branch. The maximum
number of upstream pipeline subscriptions is 2 by default, for both the upstream and
The maximum number of upstream pipeline subscriptions is 2 by default, for both the upstream and
downstream projects. On self-managed instances, an administrator can change this
[limit](../../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project).

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

@ -12,185 +12,193 @@ DETAILS:
Predefined [CI/CD variables](index.md) are available in every GitLab CI/CD pipeline.
Predefined variables become available at two different phases of pipeline execution.
Some variables are available when GitLab creates the pipeline, and can be used to configure
the pipeline or in job scripts. The other variables become available when a runner runs the job,
and can only be used in job scripts.
Predefined variables made available by the runner cannot be used with [trigger jobs](../pipelines/downstream_pipelines.md#trigger-a-downstream-pipeline-from-a-job-in-the-gitlab-ciyml-file)
or these keywords:
- [`workflow`](../yaml/index.md#workflow)
- [`include`](../yaml/index.md#include)
- [`rules`](../yaml/index.md#rules)
NOTE:
Avoid [overriding](index.md#override-a-defined-cicd-variable) predefined variables,
as it can cause the pipeline to behave unexpectedly.
| Variable | Defined for | GitLab | Runner | Description |
|-----------------------------------|-------------|--------|--------|-------------|
| `CHAT_CHANNEL` | Pipeline | 10.6 | all | The Source chat channel that triggered the [ChatOps](../chatops/index.md) command. |
| `CHAT_INPUT` | Pipeline | 10.6 | all | The additional arguments passed with the [ChatOps](../chatops/index.md) command. |
| `CHAT_USER_ID` | Pipeline | 14.4 | all | The chat service's user ID of the user who triggered the [ChatOps](../chatops/index.md) command. |
| `CI` | Pipeline | all | 0.4 | Available for all jobs executed in CI/CD. `true` when available. |
| `CI_API_V4_URL` | Pipeline | 11.7 | all | The GitLab API v4 root URL. |
| `CI_API_GRAPHQL_URL` | Pipeline | 15.11 | all | The GitLab API GraphQL root URL. |
| `CI_BUILDS_DIR` | Jobs only | all | 11.10 | The top-level directory where builds are executed. |
| `CI_COMMIT_AUTHOR` | Pipeline | 13.11 | all | The author of the commit in `Name <email>` format. |
| `CI_COMMIT_BEFORE_SHA` | Pipeline | 11.2 | all | The previous latest commit present on a branch or tag. Is always `0000000000000000000000000000000000000000` for merge request pipelines, the first commit in pipelines for branches or tags, or when manually running a pipeline. |
| `CI_COMMIT_BRANCH` | Pipeline | 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` | Pipeline | 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` | Pipeline | 10.8 | all | The full commit message. |
| `CI_COMMIT_REF_NAME` | Pipeline | 9.0 | all | The branch or tag name for which project is built. |
| `CI_COMMIT_REF_PROTECTED` | Pipeline | 11.11 | all | `true` if the job is running for a protected reference, `false` otherwise. |
| `CI_COMMIT_REF_SLUG` | Pipeline | 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` | Pipeline | 9.0 | all | The commit revision the project is built for. |
| `CI_COMMIT_SHORT_SHA` | Pipeline | 11.7 | all | The first eight characters of `CI_COMMIT_SHA`. |
| `CI_COMMIT_TAG` | Pipeline | 9.0 | 0.5 | The commit tag name. Available only in pipelines for tags. |
| `CI_COMMIT_TAG_MESSAGE` | Pipeline | 15.5 | all | The commit tag message. Available only in pipelines for tags. |
| `CI_COMMIT_TIMESTAMP` | Pipeline | 13.4 | all | The timestamp of the commit in the [ISO 8601](https://www.rfc-editor.org/rfc/rfc3339#appendix-A) format. For example, `2022-01-31T16:47:55Z`. [UTC by default](../../administration/timezone.md). |
| `CI_COMMIT_TITLE` | Pipeline | 10.8 | all | The title of the commit. The full first line of the message. |
| `CI_CONCURRENT_ID` | Jobs only | all | 11.10 | The unique ID of build execution in a single executor. |
| `CI_CONCURRENT_PROJECT_ID` | Jobs only | all | 11.10 | The unique ID of build execution in a single executor and project. |
| `CI_CONFIG_PATH` | Pipeline | 9.4 | 0.5 | The path to the CI/CD configuration file. Defaults to `.gitlab-ci.yml`. |
| `CI_DEBUG_TRACE` | Pipeline | all | 1.7 | `true` if [debug logging (tracing)](index.md#enable-debug-logging) is enabled. |
| `CI_DEBUG_SERVICES` | Pipeline | 15.7 | 15.7 | `true` if [service container logging](../services/index.md#capturing-service-container-logs) is enabled. |
| `CI_DEFAULT_BRANCH` | Pipeline | 12.4 | all | The name of the project's default branch. |
| `CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX`| Pipeline | 14.3 | all | The direct group image prefix for pulling images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX` | Pipeline | 13.7 | all | The top-level group image prefix for pulling images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_PASSWORD` | Pipeline | 13.7 | all | The password to pull images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_SERVER` | Pipeline | 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` | Pipeline | 13.7 | all | The username to pull images through the Dependency Proxy. |
| `CI_DEPLOY_FREEZE` | Pipeline | 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` | Jobs only | 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` | Jobs only | 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` | Pipeline | 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` | Pipeline | 8.15 | all | The name of the environment for this job. Available if [`environment:name`](../yaml/index.md#environmentname) is set. |
| `CI_ENVIRONMENT_SLUG` | Pipeline | 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/index.md#environmentname) is set. The slug is [truncated to 24 characters](https://gitlab.com/gitlab-org/gitlab/-/issues/20941). A random suffix is automatically added to [uppercase environment names](https://gitlab.com/gitlab-org/gitlab/-/issues/415526). |
| `CI_ENVIRONMENT_URL` | Pipeline | 9.3 | all | The URL of the environment for this job. Available if [`environment:url`](../yaml/index.md#environmenturl) is set. |
| `CI_ENVIRONMENT_ACTION` | Pipeline | 13.11 | all | The action annotation specified for this job's environment. Available if [`environment:action`](../yaml/index.md#environmentaction) is set. Can be `start`, `prepare`, or `stop`. |
| `CI_ENVIRONMENT_TIER` | Pipeline | 14.0 | all | The [deployment tier of the environment](../environments/index.md#deployment-tier-of-environments) for this job. |
| `CI_GITLAB_FIPS_MODE` | Pipeline | 14.10 | all | Only available if [FIPS mode](../../development/fips_compliance.md) is enabled in the GitLab instance. `true` when available. |
| `CI_HAS_OPEN_REQUIREMENTS` | Pipeline | 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` | Jobs only | 9.0 | all | The internal ID of the job, unique across all jobs in the GitLab instance. |
| `CI_JOB_IMAGE` | Pipeline | 12.9 | 12.9 | The name of the Docker image running the job. |
| `CI_JOB_JWT` (Deprecated) | Pipeline | 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). [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 17.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
| `CI_JOB_JWT_V1` (Deprecated) | Pipeline | 14.6 | all | The same value as `CI_JOB_JWT`. [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 17.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
| `CI_JOB_JWT_V2` (Deprecated) | Pipeline | 14.6 | all | A newly formatted RS256 JSON web token to increase compatibility. Similar to `CI_JOB_JWT`, except the issuer (`iss`) claim is changed from `gitlab.com` to `https://gitlab.com`, `sub` has changed from `job_id` to a string that contains the project path, and an `aud` claim is added. The `aud` field is a constant value. Trusting JWTs in multiple relying parties can lead to [one RP sending a JWT to another one and acting maliciously as a job](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72555#note_769112331). [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 17.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
| `CI_JOB_MANUAL` | Pipeline | 8.12 | all | Only available if the job was started manually. `true` when available. |
| `CI_JOB_NAME` | Pipeline | 9.0 | 0.5 | The name of the job. |
| `CI_JOB_NAME_SLUG` | Pipeline | 15.4 | all | `CI_JOB_NAME` in lowercase, shortened to 63 bytes, and with everything except `0-9` and `a-z` replaced with `-`. No leading / trailing `-`. Use in paths. |
| `CI_JOB_STAGE` | Pipeline | 9.0 | 0.5 | The name of the job's stage. |
| `CI_JOB_STATUS` | Jobs only | all | 13.5 | The status of the job as each runner stage is executed. Use with [`after_script`](../yaml/index.md#after_script). Can be `success`, `failed`, or `canceled`. |
| `CI_JOB_TIMEOUT` | Jobs only | 15.7 | 15.7 | The job timeout, in seconds. |
| `CI_JOB_TOKEN` | Jobs only | 9.0 | 1.2 | A token to authenticate with [certain API endpoints](../jobs/ci_job_token.md). The token is valid as long as the job is running. |
| `CI_JOB_URL` | Jobs only | 11.1 | 0.5 | The job details URL. |
| `CI_JOB_STARTED_AT` | Jobs only | 13.10 | all | The date and time when a job started, in [ISO 8601](https://www.rfc-editor.org/rfc/rfc3339#appendix-A) format. For example, `2022-01-31T16:47:55Z`. [UTC by default](../../administration/timezone.md). |
| `CI_KUBERNETES_ACTIVE` | Pipeline | 13.0 | all | Only available if the pipeline has a Kubernetes cluster available for deployments. `true` when available. |
| `CI_NODE_INDEX` | Pipeline | 11.5 | all | The index of the job in the job set. Only available if the job uses [`parallel`](../yaml/index.md#parallel). |
| `CI_NODE_TOTAL` | Pipeline | 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/index.md#parallel). |
| `CI_OPEN_MERGE_REQUESTS` | Pipeline | 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` | Pipeline | 11.8 | all | The configured domain that hosts GitLab Pages. |
| `CI_PAGES_URL` | Pipeline | 11.8 | all | The URL for a GitLab Pages site. Always a subdomain of `CI_PAGES_DOMAIN`. |
| `CI_PIPELINE_ID` | Jobs only | 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` | Pipeline | 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` | Pipeline | 10.0 | all | How the pipeline was triggered. The value can be one of the [pipeline sources](../jobs/job_rules.md#ci_pipeline_source-predefined-variable). |
| `CI_PIPELINE_TRIGGERED` | Pipeline | all | all | `true` if the job was [triggered](../triggers/index.md). |
| `CI_PIPELINE_URL` | Jobs only | 11.1 | 0.5 | The URL for the pipeline details. |
| `CI_PIPELINE_CREATED_AT` | Pipeline | 13.10 | all | The date and time when the pipeline was created, in [ISO 8601](https://www.rfc-editor.org/rfc/rfc3339#appendix-A) format. For example, `2022-01-31T16:47:55Z`. [UTC by default](../../administration/timezone.md). |
| `CI_PIPELINE_NAME` | Pipeline | 16.3 | all | The pipeline name defined in [`workflow:name`](../yaml/index.md#workflowname) |
| `CI_PROJECT_DIR` | Jobs only | 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` | Pipeline | all | all | The ID of the current project. This ID is unique across all projects on the GitLab instance. |
| `CI_PROJECT_NAME` | Pipeline | 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` | Pipeline | 8.10 | 0.5 | The project namespace (username or group name) of the job. |
| `CI_PROJECT_NAMESPACE_ID` | Pipeline | 15.7 | 0.5 | The project namespace ID of the job. |
| `CI_PROJECT_PATH_SLUG` | Pipeline | 9.3 | all | `$CI_PROJECT_PATH` in lowercase with characters that are not `a-z` or `0-9` replaced with `-` and shortened to 63 bytes. Use in URLs and domain names. |
| `CI_PROJECT_PATH` | Pipeline | 8.10 | 0.5 | The project namespace with the project name included. |
| `CI_PROJECT_REPOSITORY_LANGUAGES` | Pipeline | 12.3 | all | A comma-separated, lowercase list of the languages used in the repository. For example `ruby,javascript,html,css`. The maximum number of languages is limited to 5. An issue [proposes to increase the limit](https://gitlab.com/gitlab-org/gitlab/-/issues/368925). |
| `CI_PROJECT_ROOT_NAMESPACE` | Pipeline | 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` | Pipeline | 12.4 | all | The human-readable project name as displayed in the GitLab web interface. |
| `CI_PROJECT_DESCRIPTION` | Pipeline | 15.1 | all | The project description as displayed in the GitLab web interface. |
| `CI_PROJECT_URL` | Pipeline | 8.10 | 0.5 | The HTTP(S) address of the project. |
| `CI_PROJECT_VISIBILITY` | Pipeline | 10.3 | all | The project visibility. Can be `internal`, `private`, or `public`. |
| `CI_PROJECT_CLASSIFICATION_LABEL` | Pipeline | 14.2 | all | The project [external authorization classification label](../../administration/settings/external_authorization.md). |
| `CI_REGISTRY` | Pipeline | 8.10 | 0.5 | Address of the [container registry](../../user/packages/container_registry/index.md) server, formatted as `<host>[:<port>]`. For example: `registry.gitlab.example.com`. Only available if the container registry is enabled for the GitLab instance. |
| `CI_REGISTRY_IMAGE` | Pipeline | 8.10 | 0.5 | Base address for the container registry to push, pull, or tag project's images, formatted as `<host>[:<port>]/<project_full_path>`. For example: `registry.gitlab.example.com/my_group/my_project`. Image names must follow the [container registry naming convention](../../user/packages/container_registry/index.md#naming-convention-for-your-container-images). Only available if the container registry is enabled for the project. |
| `CI_REGISTRY_PASSWORD` | Jobs only | 9.0 | all | The password to push containers to the GitLab project's container registry. Only available if the container registry is enabled for the project. This password value is the same as the `CI_JOB_TOKEN` and is valid only as long as the job is running. Use the `CI_DEPLOY_PASSWORD` for long-lived access to the registry |
| `CI_REGISTRY_USER` | Jobs only | 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_RELEASE_DESCRIPTION` | Pipeline | 15.5 | all | The description of the release. Available only on pipelines for tags. Description length is limited to first 1024 characters. |
| `CI_REPOSITORY_URL` | Jobs only | 9.0 | all | The full path to Git clone (HTTP) the repository with a [CI/CD job token](../jobs/ci_job_token.md), in the format `https://gitlab-ci-token:$CI_JOB_TOKEN@gitlab.example.com/my-group/my-project.git`. |
| `CI_RUNNER_DESCRIPTION` | Jobs only | 8.10 | 0.5 | The description of the runner. |
| `CI_RUNNER_EXECUTABLE_ARCH` | Jobs only | 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` | Jobs only | 8.10 | 0.5 | The unique ID of the runner being used. |
| `CI_RUNNER_REVISION` | Jobs only | all | 10.6 | The revision of the runner running the job. |
| `CI_RUNNER_SHORT_TOKEN` | Jobs only | all | 12.3 | The runner's unique ID, used to authenticate new job requests. The token contains a prefix, and the first 17 characters are used. |
| `CI_RUNNER_TAGS` | Jobs only | 8.10 | 0.5 | A comma-separated list of the runner tags. |
| `CI_RUNNER_VERSION` | Jobs only | all | 10.6 | The version of the GitLab Runner running the job. |
| `CI_SERVER_FQDN` | Pipeline | 16.10 | all | The fully qualified domain name (FQDN) of the instance. For example `gitlab.example.com:8080`. |
| `CI_SERVER_HOST` | Pipeline | 12.1 | all | The host of the GitLab instance URL, without protocol or port. For example `gitlab.example.com`. |
| `CI_SERVER_NAME` | Pipeline | all | all | The name of CI/CD server that coordinates jobs. |
| `CI_SERVER_PORT` | Pipeline | 12.8 | all | The port of the GitLab instance URL, without host or protocol. For example `8080`. |
| `CI_SERVER_PROTOCOL` | Pipeline | 12.8 | all | The protocol of the GitLab instance URL, without host or port. For example `https`. |
| `CI_SERVER_SHELL_SSH_HOST` | Pipeline | 15.11 | all | The SSH host of the GitLab instance, used for access to Git repositories via SSH. For example `gitlab.com`. |
| `CI_SERVER_SHELL_SSH_PORT` | Pipeline | 15.11 | all | The SSH port of the GitLab instance, used for access to Git repositories via SSH. For example `22`. |
| `CI_SERVER_REVISION` | Pipeline | all | all | GitLab revision that schedules jobs. |
| `CI_SERVER_TLS_CA_FILE` | Pipeline | all | all | File containing the TLS CA certificate to verify the GitLab server when `tls-ca-file` set in [runner settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section). |
| `CI_SERVER_TLS_CERT_FILE` | Pipeline | all | all | File containing the TLS certificate to verify the GitLab server when `tls-cert-file` set in [runner settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section). |
| `CI_SERVER_TLS_KEY_FILE` | Pipeline | all | all | File containing the TLS key to verify the GitLab server when `tls-key-file` set in [runner settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section). |
| `CI_SERVER_URL` | Pipeline | 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` | Pipeline | 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` | Pipeline | 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` | Pipeline | 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` | Pipeline | all | all | The full version of the GitLab instance. |
| `CI_SERVER` | Jobs only | all | all | Available for all jobs executed in CI/CD. `yes` when available. |
| `CI_SHARED_ENVIRONMENT` | Pipeline | 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. |
| `CI_TEMPLATE_REGISTRY_HOST` | Pipeline | 15.3 | all | The host of the registry used by CI/CD templates. Defaults to `registry.gitlab.com`. |
| `CI_TRIGGER_SHORT_TOKEN` | Jobs only | 17.0 | all | First 4 characters of the [trigger token](../triggers/index.md#create-a-pipeline-trigger-token) of the current job. Only available if the pipeline was [triggered with a trigger token](../triggers/index.md). For example, for a trigger token of `glptt-dbf556605bcad4d9db3ec5fcef84f78f9b4fec28`, `CI_TRIGGER_SHORT_TOKEN` would be `dbf5`. |
| `GITLAB_CI` | Pipeline | all | all | Available for all jobs executed in CI/CD. `true` when available. |
| `GITLAB_FEATURES` | Pipeline | 10.6 | all | The comma-separated list of licensed features available for the GitLab instance and license. |
| `GITLAB_USER_EMAIL` | Pipeline | 8.12 | all | The email of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the email of the user who started the job. |
| `GITLAB_USER_ID` | Pipeline | 8.12 | all | The numeric ID of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the ID of the user who started the job. |
| `GITLAB_USER_LOGIN` | Pipeline | 10.0 | all | The unique username of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the username of the user who started the job. |
| `GITLAB_USER_NAME` | Pipeline | 10.0 | all | The display name (user-defined **Full name** in the profile settings) of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the name of the user who started the job. |
| `KUBECONFIG` | Pipeline | 14.2 | all | The path to the `kubeconfig` file with contexts for every shared agent connection. Only available when a [GitLab agent is authorized to access the project](../../user/clusters/agent/ci_cd_workflow.md#authorize-the-agent). |
| `TRIGGER_PAYLOAD` | Pipeline | 13.9 | all | The webhook payload. Only available when a pipeline is [triggered with a webhook](../triggers/index.md#access-webhook-payload). |
## Variable availability
Predefined variables become available at three different phases of pipeline execution:
- Pre-pipeline: Pre-pipeline variables are available before the pipeline is created.
These variables are the only variables that can be used with [`include:rules`](../yaml/index.md#includerules)
to control which configuration files to use when creating the pipeline.
- Pipeline: Pipeline variables become available when GitLab is creating the pipeline.
Along with pre-pipeline variables, pipeline variables can be used to configure
[`rules`](../yaml/index.md#rules) defined in jobs, to determine which jobs to add to the pipeline.
- Job-only: These variables are only made available to each job when a runner picks
up the job and runs it, and:
- Can be used in job scripts.
- Cannot be used with [trigger jobs](../pipelines/downstream_pipelines.md#trigger-a-downstream-pipeline-from-a-job-in-the-gitlab-ciyml-file).
- Cannot be used with [`workflow`](../yaml/index.md#workflow), [`include`](../yaml/index.md#include)
or [`rules`](../yaml/index.md#rules).
## Predefined variables
| Variable | Availability | Description |
|-------------------------------------------------|--------------|-------------|
| `CHAT_CHANNEL` | Pipeline | The Source chat channel that triggered the [ChatOps](../chatops/index.md) command. |
| `CHAT_INPUT` | Pipeline | The additional arguments passed with the [ChatOps](../chatops/index.md) command. |
| `CHAT_USER_ID` | Pipeline | The chat service's user ID of the user who triggered the [ChatOps](../chatops/index.md) command. |
| `CI` | Pipeline | Available for all jobs executed in CI/CD. `true` when available. |
| `CI_API_V4_URL` | Pipeline | The GitLab API v4 root URL. |
| `CI_API_GRAPHQL_URL` | Pipeline | The GitLab API GraphQL root URL. Introduced in GitLab 15.11. |
| `CI_BUILDS_DIR` | Job-only | The top-level directory where builds are executed. |
| `CI_COMMIT_AUTHOR` | Pre-pipeline | The author of the commit in `Name <email>` format. |
| `CI_COMMIT_BEFORE_SHA` | Pre-pipeline | The previous latest commit present on a branch or tag. Is always `0000000000000000000000000000000000000000` for merge request pipelines, the first commit in pipelines for branches or tags, or when manually running a pipeline. |
| `CI_COMMIT_BRANCH` | Pre-pipeline | 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` | Pre-pipeline | The description of the commit. If the title is shorter than 100 characters, the message without the first line. |
| `CI_COMMIT_MESSAGE` | Pre-pipeline | The full commit message. |
| `CI_COMMIT_REF_NAME` | Pre-pipeline | The branch or tag name for which project is built. |
| `CI_COMMIT_REF_PROTECTED` | Pre-pipeline | `true` if the job is running for a protected reference, `false` otherwise. |
| `CI_COMMIT_REF_SLUG` | Pre-pipeline | `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` | Pre-pipeline | The commit revision the project is built for. |
| `CI_COMMIT_SHORT_SHA` | Pre-pipeline | The first eight characters of `CI_COMMIT_SHA`. |
| `CI_COMMIT_TAG` | Pre-pipeline | The commit tag name. Available only in pipelines for tags. |
| `CI_COMMIT_TAG_MESSAGE` | Pre-pipeline | The commit tag message. Available only in pipelines for tags. Introduced in GitLab 15.5. |
| `CI_COMMIT_TIMESTAMP` | Pre-pipeline | The timestamp of the commit in the [ISO 8601](https://www.rfc-editor.org/rfc/rfc3339#appendix-A) format. For example, `2022-01-31T16:47:55Z`. [UTC by default](../../administration/timezone.md). |
| `CI_COMMIT_TITLE` | Pre-pipeline | The title of the commit. The full first line of the message. |
| `CI_CONCURRENT_ID` | Job-only | The unique ID of build execution in a single executor. |
| `CI_CONCURRENT_PROJECT_ID` | Job-only | The unique ID of build execution in a single executor and project. |
| `CI_CONFIG_PATH` | Pipeline | The path to the CI/CD configuration file. Defaults to `.gitlab-ci.yml`. |
| `CI_DEBUG_TRACE` | Pipeline | `true` if [debug logging (tracing)](index.md#enable-debug-logging) is enabled. |
| `CI_DEBUG_SERVICES` | Pipeline | `true` if [service container logging](../services/index.md#capturing-service-container-logs) is enabled. Introduced in GitLab 15.7. Requires GitLab Runner 15.7. |
| `CI_DEFAULT_BRANCH` | Pipeline | The name of the project's default branch. |
| `CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX` | Pipeline | The direct group image prefix for pulling images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX` | Pipeline | The top-level group image prefix for pulling images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_PASSWORD` | Pipeline | The password to pull images through the Dependency Proxy. |
| `CI_DEPENDENCY_PROXY_SERVER` | Pipeline | The server for logging in to the Dependency Proxy. This variable is equivalent to `$CI_SERVER_HOST:$CI_SERVER_PORT`. |
| `CI_DEPENDENCY_PROXY_USER` | Pipeline | The username to pull images through the Dependency Proxy. |
| `CI_DEPLOY_FREEZE` | Pre-pipeline | 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` | Job-only | 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` | Job-only | 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` | Pipeline | 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` | Pipeline | The name of the environment for this job. Available if [`environment:name`](../yaml/index.md#environmentname) is set. |
| `CI_ENVIRONMENT_SLUG` | Pipeline | The simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Available if [`environment:name`](../yaml/index.md#environmentname) is set. The slug is [truncated to 24 characters](https://gitlab.com/gitlab-org/gitlab/-/issues/20941). A random suffix is automatically added to [uppercase environment names](https://gitlab.com/gitlab-org/gitlab/-/issues/415526). |
| `CI_ENVIRONMENT_URL` | Pipeline | The URL of the environment for this job. Available if [`environment:url`](../yaml/index.md#environmenturl) is set. |
| `CI_ENVIRONMENT_ACTION` | Pipeline | The action annotation specified for this job's environment. Available if [`environment:action`](../yaml/index.md#environmentaction) is set. Can be `start`, `prepare`, or `stop`. |
| `CI_ENVIRONMENT_TIER` | Pipeline | The [deployment tier of the environment](../environments/index.md#deployment-tier-of-environments) for this job. |
| `CI_GITLAB_FIPS_MODE` | Pre-pipeline | Only available if [FIPS mode](../../development/fips_compliance.md) is enabled in the GitLab instance. `true` when available. |
| `CI_HAS_OPEN_REQUIREMENTS` | Pipeline | Only available if the pipeline's project has an open [requirement](../../user/project/requirements/index.md). `true` when available. |
| `CI_JOB_ID` | Job-only | The internal ID of the job, unique across all jobs in the GitLab instance. |
| `CI_JOB_IMAGE` | Pipeline | The name of the Docker image running the job. |
| `CI_JOB_JWT` (Deprecated) | Pipeline | A RS256 JSON web token to authenticate with third party systems that support JWT authentication, for example [HashiCorp's Vault](../secrets/index.md). [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 17.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
| `CI_JOB_JWT_V1` (Deprecated) | Pipeline | The same value as `CI_JOB_JWT`. [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 17.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
| `CI_JOB_JWT_V2` (Deprecated) | Pipeline | A newly formatted RS256 JSON web token to increase compatibility. Similar to `CI_JOB_JWT`, except the issuer (`iss`) claim is changed from `gitlab.com` to `https://gitlab.com`, `sub` has changed from `job_id` to a string that contains the project path, and an `aud` claim is added. The `aud` field is a constant value. Trusting JWTs in multiple relying parties can lead to [one RP sending a JWT to another one and acting maliciously as a job](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72555#note_769112331). [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 17.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
| `CI_JOB_MANUAL` | Pipeline | Only available if the job was started manually. `true` when available. |
| `CI_JOB_NAME` | Pipeline | The name of the job. |
| `CI_JOB_NAME_SLUG` | Pipeline | `CI_JOB_NAME` in lowercase, shortened to 63 bytes, and with everything except `0-9` and `a-z` replaced with `-`. No leading / trailing `-`. Use in paths. Introduced in GitLab 15.4. |
| `CI_JOB_STAGE` | Pipeline | The name of the job's stage. |
| `CI_JOB_STATUS` | Job-only | The status of the job as each runner stage is executed. Use with [`after_script`](../yaml/index.md#after_script). Can be `success`, `failed`, or `canceled`. |
| `CI_JOB_TIMEOUT` | Job-only | The job timeout, in seconds. Introduced in GitLab 15.7. Requires GitLab Runner 15.7. |
| `CI_JOB_TOKEN` | Job-only | A token to authenticate with [certain API endpoints](../jobs/ci_job_token.md). The token is valid as long as the job is running. |
| `CI_JOB_URL` | Job-only | The job details URL. |
| `CI_JOB_STARTED_AT` | Job-only | The date and time when a job started, in [ISO 8601](https://www.rfc-editor.org/rfc/rfc3339#appendix-A) format. For example, `2022-01-31T16:47:55Z`. [UTC by default](../../administration/timezone.md). |
| `CI_KUBERNETES_ACTIVE` | Pre-pipeline | Only available if the pipeline has a Kubernetes cluster available for deployments. `true` when available. |
| `CI_NODE_INDEX` | Pipeline | The index of the job in the job set. Only available if the job uses [`parallel`](../yaml/index.md#parallel). |
| `CI_NODE_TOTAL` | Pipeline | The total number of instances of this job running in parallel. Set to `1` if the job does not use [`parallel`](../yaml/index.md#parallel). |
| `CI_OPEN_MERGE_REQUESTS` | Pre-pipeline | 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` | Pipeline | The configured domain that hosts GitLab Pages. |
| `CI_PAGES_URL` | Pipeline | The URL for a GitLab Pages site. Always a subdomain of `CI_PAGES_DOMAIN`. |
| `CI_PIPELINE_ID` | Job-only | The instance-level ID of the current pipeline. This ID is unique across all projects on the GitLab instance. |
| `CI_PIPELINE_IID` | Pipeline | The project-level IID (internal ID) of the current pipeline. This ID is unique only in the current project. |
| `CI_PIPELINE_SOURCE` | Pre-pipeline | How the pipeline was triggered. The value can be one of the [pipeline sources](../jobs/job_rules.md#ci_pipeline_source-predefined-variable). |
| `CI_PIPELINE_TRIGGERED` | Pipeline | `true` if the job was [triggered](../triggers/index.md). |
| `CI_PIPELINE_URL` | Job-only | The URL for the pipeline details. |
| `CI_PIPELINE_CREATED_AT` | Pre-pipeline | The date and time when the pipeline was created, in [ISO 8601](https://www.rfc-editor.org/rfc/rfc3339#appendix-A) format. For example, `2022-01-31T16:47:55Z`. [UTC by default](../../administration/timezone.md). |
| `CI_PIPELINE_NAME` | Pre-pipeline | The pipeline name defined in [`workflow:name`](../yaml/index.md#workflowname). Introduced in GitLab 16.3. |
| `CI_PROJECT_DIR` | Job-only | 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` | Pipeline | The ID of the current project. This ID is unique across all projects on the GitLab instance. |
| `CI_PROJECT_NAME` | Pipeline | 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` | Pipeline | The project namespace (username or group name) of the job. |
| `CI_PROJECT_NAMESPACE_ID` | Pipeline | The project namespace ID of the job. Introduced in GitLab 15.7. |
| `CI_PROJECT_PATH_SLUG` | Pipeline | `$CI_PROJECT_PATH` in lowercase with characters that are not `a-z` or `0-9` replaced with `-` and shortened to 63 bytes. Use in URLs and domain names. |
| `CI_PROJECT_PATH` | Pipeline | The project namespace with the project name included. |
| `CI_PROJECT_REPOSITORY_LANGUAGES` | Pipeline | A comma-separated, lowercase list of the languages used in the repository. For example `ruby,javascript,html,css`. The maximum number of languages is limited to 5. An issue [proposes to increase the limit](https://gitlab.com/gitlab-org/gitlab/-/issues/368925). |
| `CI_PROJECT_ROOT_NAMESPACE` | Pipeline | 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` | Pipeline | The human-readable project name as displayed in the GitLab web interface. |
| `CI_PROJECT_DESCRIPTION` | Pipeline | The project description as displayed in the GitLab web interface. Introduced in GitLab 15.1. |
| `CI_PROJECT_URL` | Pipeline | The HTTP(S) address of the project. |
| `CI_PROJECT_VISIBILITY` | Pipeline | The project visibility. Can be `internal`, `private`, or `public`. |
| `CI_PROJECT_CLASSIFICATION_LABEL` | Pipeline | The project [external authorization classification label](../../administration/settings/external_authorization.md). |
| `CI_REGISTRY` | Pipeline | Address of the [container registry](../../user/packages/container_registry/index.md) server, formatted as `<host>[:<port>]`. For example: `registry.gitlab.example.com`. Only available if the container registry is enabled for the GitLab instance. |
| `CI_REGISTRY_IMAGE` | Pipeline | Base address for the container registry to push, pull, or tag project's images, formatted as `<host>[:<port>]/<project_full_path>`. For example: `registry.gitlab.example.com/my_group/my_project`. Image names must follow the [container registry naming convention](../../user/packages/container_registry/index.md#naming-convention-for-your-container-images). Only available if the container registry is enabled for the project. |
| `CI_REGISTRY_PASSWORD` | Job-only | The password to push containers to the GitLab project's container registry. Only available if the container registry is enabled for the project. This password value is the same as the `CI_JOB_TOKEN` and is valid only as long as the job is running. Use the `CI_DEPLOY_PASSWORD` for long-lived access to the registry |
| `CI_REGISTRY_USER` | Job-only | The username to push containers to the project's GitLab container registry. Only available if the container registry is enabled for the project. |
| `CI_RELEASE_DESCRIPTION` | Pipeline | The description of the release. Available only on pipelines for tags. Description length is limited to first 1024 characters. Introduced in GitLab 15.5. |
| `CI_REPOSITORY_URL` | Job-only | The full path to Git clone (HTTP) the repository with a [CI/CD job token](../jobs/ci_job_token.md), in the format `https://gitlab-ci-token:$CI_JOB_TOKEN@gitlab.example.com/my-group/my-project.git`. |
| `CI_RUNNER_DESCRIPTION` | Job-only | The description of the runner. |
| `CI_RUNNER_EXECUTABLE_ARCH` | Job-only | The OS/architecture of the GitLab Runner executable. Might not be the same as the environment of the executor. |
| `CI_RUNNER_ID` | Job-only | The unique ID of the runner being used. |
| `CI_RUNNER_REVISION` | Job-only | The revision of the runner running the job. |
| `CI_RUNNER_SHORT_TOKEN` | Job-only | The runner's unique ID, used to authenticate new job requests. The token contains a prefix, and the first 17 characters are used. |
| `CI_RUNNER_TAGS` | Job-only | A comma-separated list of the runner tags. |
| `CI_RUNNER_VERSION` | Job-only | The version of the GitLab Runner running the job. |
| `CI_SERVER_FQDN` | Pipeline | The fully qualified domain name (FQDN) of the instance. For example `gitlab.example.com:8080`. Introduced in GitLab 16.10. |
| `CI_SERVER_HOST` | Pipeline | The host of the GitLab instance URL, without protocol or port. For example `gitlab.example.com`. |
| `CI_SERVER_NAME` | Pipeline | The name of CI/CD server that coordinates jobs. |
| `CI_SERVER_PORT` | Pipeline | The port of the GitLab instance URL, without host or protocol. For example `8080`. |
| `CI_SERVER_PROTOCOL` | Pipeline | The protocol of the GitLab instance URL, without host or port. For example `https`. |
| `CI_SERVER_SHELL_SSH_HOST` | Pipeline | The SSH host of the GitLab instance, used for access to Git repositories through SSH. For example `gitlab.com`. Introduced in GitLab 15.11. |
| `CI_SERVER_SHELL_SSH_PORT` | Pipeline | The SSH port of the GitLab instance, used for access to Git repositories through SSH. For example `22`. Introduced in GitLab 15.11. |
| `CI_SERVER_REVISION` | Pipeline | GitLab revision that schedules jobs. |
| `CI_SERVER_TLS_CA_FILE` | Pipeline | File containing the TLS CA certificate to verify the GitLab server when `tls-ca-file` set in [runner settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section). |
| `CI_SERVER_TLS_CERT_FILE` | Pipeline | File containing the TLS certificate to verify the GitLab server when `tls-cert-file` set in [runner settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section). |
| `CI_SERVER_TLS_KEY_FILE` | Pipeline | File containing the TLS key to verify the GitLab server when `tls-key-file` set in [runner settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section). |
| `CI_SERVER_URL` | Pipeline | The base URL of the GitLab instance, including protocol and port. For example `https://gitlab.example.com:8080`. |
| `CI_SERVER_VERSION_MAJOR` | Pipeline | The major version of the GitLab instance. For example, if the GitLab version is `17.2.1`, the `CI_SERVER_VERSION_MAJOR` is `17`. |
| `CI_SERVER_VERSION_MINOR` | Pipeline | The minor version of the GitLab instance. For example, if the GitLab version is `17.2.1`, the `CI_SERVER_VERSION_MINOR` is `2`. |
| `CI_SERVER_VERSION_PATCH` | Pipeline | The patch version of the GitLab instance. For example, if the GitLab version is `17.2.1`, the `CI_SERVER_VERSION_PATCH` is `1`. |
| `CI_SERVER_VERSION` | Pipeline | The full version of the GitLab instance. |
| `CI_SERVER` | Job-only | Available for all jobs executed in CI/CD. `yes` when available. |
| `CI_SHARED_ENVIRONMENT` | Pipeline | 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. |
| `CI_TEMPLATE_REGISTRY_HOST` | Pipeline | The host of the registry used by CI/CD templates. Defaults to `registry.gitlab.com`. Introduced in GitLab 15.3. |
| `CI_TRIGGER_SHORT_TOKEN` | Job-only | First 4 characters of the [trigger token](../triggers/index.md#create-a-pipeline-trigger-token) of the current job. Only available if the pipeline was [triggered with a trigger token](../triggers/index.md). For example, for a trigger token of `glptt-dbf556605bcad4d9db3ec5fcef84f78f9b4fec28`, `CI_TRIGGER_SHORT_TOKEN` would be `dbf5`. Introduced in GitLab 17.0. |
| `GITLAB_CI` | Pipeline | Available for all jobs executed in CI/CD. `true` when available. |
| `GITLAB_FEATURES` | Pipeline | The comma-separated list of licensed features available for the GitLab instance and license. |
| `GITLAB_USER_EMAIL` | Pipeline | The email of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the email of the user who started the job. |
| `GITLAB_USER_ID` | Pipeline | The numeric ID of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the ID of the user who started the job. |
| `GITLAB_USER_LOGIN` | Pipeline | The unique username of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the username of the user who started the job. |
| `GITLAB_USER_NAME` | Pipeline | The display name (user-defined **Full name** in the profile settings) of the user who started the pipeline, unless the job is a manual job. In manual jobs, the value is the name of the user who started the job. |
| `KUBECONFIG` | Pipeline | The path to the `kubeconfig` file with contexts for every shared agent connection. Only available when a [GitLab agent is authorized to access the project](../../user/clusters/agent/ci_cd_workflow.md#authorize-the-agent). |
| `TRIGGER_PAYLOAD` | Pipeline | The webhook payload. Only available when a pipeline is [triggered with a webhook](../triggers/index.md#access-webhook-payload). |
## Predefined variables for merge request pipelines
These variables are available when:
These variables are available before GitLab creates the pipeline (Pre-pipeline).
These variables can be used with `include:rules` to control which configuration files
to use when creating the pipeline.
- The pipelines [are merge request pipelines](../pipelines/merge_request_pipelines.md).
- The merge request is open.
The pipeline must be a [merge request pipeline](../pipelines/merge_request_pipelines.md),
and the merge request must be open.
| Variable | GitLab | Runner | Description |
|---------------------------------------------|--------|--------|-------------|
| `CI_MERGE_REQUEST_APPROVED` | 14.1 | all | Approval status of the merge request. `true` when [merge request approvals](../../user/project/merge_requests/approvals/index.md) is available and the merge request has been approved. |
| `CI_MERGE_REQUEST_ASSIGNEES` | 11.9 | all | Comma-separated list of usernames of assignees for the merge request. |
| `CI_MERGE_REQUEST_DIFF_BASE_SHA` | 13.7 | all | The base SHA of the merge request diff. |
| `CI_MERGE_REQUEST_DIFF_ID` | 13.7 | all | The version of the merge request diff. |
| `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_DESCRIPTION` | 16.7 | all | The description of the merge request. If the description is more than 2700 characters long, only the first 2700 characters are stored in the variable. |
| `CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATED` | 16.8 | all | `true` if `CI_MERGE_REQUEST_DESCRIPTION` is truncated down to 2700 characters because the description of the merge request is too long. |
| `CI_MERGE_REQUEST_ID` | 11.6 | all | The instance-level ID of the merge request. This is a unique ID across all projects on the GitLab instance. |
| `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, and is the number used in the merge request URL, page title, and other visible locations. |
| `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_PROTECTED` | 16.4 | all | `true` when the source branch of the merge request is [protected](../../user/project/protected_branches.md). |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
| `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_SQUASH_ON_MERGE` | 16.4 | all | `true` when the [squash on merge](../../user/project/merge_requests/squash_and_merge.md) option is set. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` | 11.6 | all | The target branch name of the merge request. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED` | 15.2 | all | `true` when the target branch of the merge request is [protected](../../user/project/protected_branches.md). |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
| `CI_MERGE_REQUEST_TITLE` | 11.9 | all | The title of the merge request. |
| Variable | Description |
|---------------------------------------------|-------------|
| `CI_MERGE_REQUEST_APPROVED` | Approval status of the merge request. `true` when [merge request approvals](../../user/project/merge_requests/approvals/index.md) is available and the merge request has been approved. |
| `CI_MERGE_REQUEST_ASSIGNEES` | Comma-separated list of usernames of assignees for the merge request. |
| `CI_MERGE_REQUEST_DIFF_BASE_SHA` | The base SHA of the merge request diff. |
| `CI_MERGE_REQUEST_DIFF_ID` | The version of the merge request diff. |
| `CI_MERGE_REQUEST_EVENT_TYPE` | The event type of the merge request. Can be `detached`, `merged_result` or `merge_train`. |
| `CI_MERGE_REQUEST_DESCRIPTION` | The description of the merge request. If the description is more than 2700 characters long, only the first 2700 characters are stored in the variable. Introduced in GitLab 16.7. |
| `CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATED` | `true` if `CI_MERGE_REQUEST_DESCRIPTION` is truncated down to 2700 characters because the description of the merge request is too long. Introduced in GitLab 16.8. |
| `CI_MERGE_REQUEST_ID` | The instance-level ID of the merge request. The ID is unique across all projects on the GitLab instance. |
| `CI_MERGE_REQUEST_IID` | The project-level IID (internal ID) of the merge request. This ID is unique for the current project, and is the number used in the merge request URL, page title, and other visible locations. |
| `CI_MERGE_REQUEST_LABELS` | Comma-separated label names of the merge request. |
| `CI_MERGE_REQUEST_MILESTONE` | The milestone title of the merge request. |
| `CI_MERGE_REQUEST_PROJECT_ID` | The ID of the project of the merge request. |
| `CI_MERGE_REQUEST_PROJECT_PATH` | The path of the project of the merge request. For example `namespace/awesome-project`. |
| `CI_MERGE_REQUEST_PROJECT_URL` | 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` | The ref path of the merge request. For example, `refs/merge-requests/1/head`. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` | The source branch name of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_PROTECTED` | `true` when the source branch of the merge request is [protected](../../user/project/protected_branches.md). Introduced in GitLab 16.4. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | The HEAD SHA of the source branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_ID` | The ID of the source project of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` | The path of the source project of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_URL` | The URL of the source project of the merge request. |
| `CI_MERGE_REQUEST_SQUASH_ON_MERGE` | `true` when the [squash on merge](../../user/project/merge_requests/squash_and_merge.md) option is set. Introduced in GitLab 16.4. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` | The target branch name of the merge request. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED` | `true` when the target branch of the merge request is [protected](../../user/project/protected_branches.md). Introduced in GitLab 15.2. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | The HEAD SHA of the target branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
| `CI_MERGE_REQUEST_TITLE` | The title of the merge request. |
## Predefined variables for external pull request pipelines
@ -199,15 +207,15 @@ 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 |
|-----------------------------------------------|--------|--------|-------------|
| `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. |
| Variable | Description |
|-----------------------------------------------|-------------|
| `CI_EXTERNAL_PULL_REQUEST_IID` | Pull request ID from GitHub. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_REPOSITORY` | The source repository name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_REPOSITORY` | The target repository name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_NAME` | The source branch name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHA` | The HEAD SHA of the source branch of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAME` | The target branch name of the pull request. |
| `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHA` | The HEAD SHA of the target branch of the pull request. |
## Deployment variables
@ -221,6 +229,31 @@ defines deployment variables that you can use with the integration.
The [documentation for each integration](../../user/project/integrations/index.md)
explains if the integration has any deployment variables available.
## Integration variables
Some integrations make variables available in jobs. These variables are available
as [job-only predefined variables](#variable-availability):
- [Harbor](../../user/project/integrations/harbor.md):
- `HARBOR_URL`
- `HARBOR_HOST`
- `HARBOR_OCI`
- `HARBOR_PROJECT`
- `HARBOR_USERNAME`
- `HARBOR_PASSWORD`
- [Apple App Store Connect](../../user/project/integrations/apple_app_store.md):
- `APP_STORE_CONNECT_API_KEY_ISSUER_ID`
- `APP_STORE_CONNECT_API_KEY_KEY_ID`
- `APP_STORE_CONNECT_API_KEY_KEY`
- `APP_STORE_CONNECT_API_KEY_IS_KEY_CONTENT_BASE64`
- [Google Play](../../user/project/integrations/google_play.md):
- `SUPPLY_PACKAGE_NAME`
- `SUPPLY_JSON_KEY_DATA`
- [Diffblue Cover](../../integration/diffblue_cover.md):
- `DIFFBLUE_LICENSE_KEY`
- `DIFFBLUE_ACCESS_TOKEN_NAME`
- `DIFFBLUE_ACCESS_TOKEN`
## Troubleshooting
You can [output the values of all variables available for a job](index.md#list-all-variables)

24
doc/ci/variables/where_variables_can_be_used.md
View File

@ -38,11 +38,9 @@ There are two places defined variables can be used. On the:
| [`environment:name`](../yaml/index.md#environmentname) | yes | GitLab | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/><br/>- `CI_ENVIRONMENT_*` variables.<br/>- [Persisted variables](#persisted-variables). |
| [`environment:url`](../yaml/index.md#environmenturl) | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/>Supported are all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules).<br/><br/>Not supported are variables defined in the GitLab Runner `config.toml` and variables created in the job's `script`. |
| [`environment:auto_stop_in`](../yaml/index.md#environmentauto_stop_in)| yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/> The value of the variable being substituted should be a period of time in a human readable natural language form. See [possible inputs](../yaml/index.md#environmentauto_stop_in) for more information.|
| [`except:variables`](../yaml/index.md#onlyvariables--exceptvariables) (Deprecated) | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- `CI_ENVIRONMENT_SLUG` variable.<br/>- [Persisted variables](#persisted-variables). |
| [`id_tokens:aud`](../yaml/index.md#id_tokens) | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. Variable expansion [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/414293) in GitLab 16.1. |
| [`image`](../yaml/index.md#image) | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| [`include`](../yaml/index.md#include) | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. <br/><br/>See [Use variables with include](../yaml/includes.md#use-variables-with-include) for more information on supported variables. |
| [`only:variables`](../yaml/index.md#onlyvariables--exceptvariables) (Deprecated) | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- `CI_ENVIRONMENT_SLUG` variable.<br/>- [Persisted variables](#persisted-variables). |
| [`resource_group`](../yaml/index.md#resource_group) | yes | GitLab | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/>- `CI_ENVIRONMENT_URL`<br/>- [Persisted variables](#persisted-variables). |
| [`rules:changes`](../yaml/index.md#ruleschanges) | no | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. |
| [`rules:changes:compare_to`](../yaml/index.md#ruleschangescompare_to) | no | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. |
@ -172,28 +170,6 @@ Job-level persisted variables:
- `CI_REGISTRY_USER`
- `CI_REPOSITORY_URL`
Persisted variables for specific integrations:
- [Harbor](../../user/project/integrations/harbor.md):
- `HARBOR_URL`
- `HARBOR_HOST`
- `HARBOR_OCI`
- `HARBOR_PROJECT`
- `HARBOR_USERNAME`
- `HARBOR_PASSWORD`
- [Apple App Store Connect](../../user/project/integrations/apple_app_store.md):
- `APP_STORE_CONNECT_API_KEY_ISSUER_ID`
- `APP_STORE_CONNECT_API_KEY_KEY_ID`
- `APP_STORE_CONNECT_API_KEY_KEY`
- `APP_STORE_CONNECT_API_KEY_IS_KEY_CONTENT_BASE64`
- [Google Play](../../user/project/integrations/google_play.md):
- `SUPPLY_PACKAGE_NAME`
- `SUPPLY_JSON_KEY_DATA`
- [Diffblue Cover](../../integration/diffblue_cover.md):
- `DIFFBLUE_LICENSE_KEY`
- `DIFFBLUE_ACCESS_TOKEN_NAME`
- `DIFFBLUE_ACCESS_TOKEN`
## Variables with an environment scope
Variables defined with an environment scope are supported. Given that

6
doc/ci/yaml/index.md
View File

@ -5228,7 +5228,7 @@ The keywords available for use in trigger jobs are:
**Possible inputs**:
- For multi-project pipelines, the path to the downstream project. CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
in GitLab 15.3 and later, but not [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
in GitLab 15.3 and later, but not [job-only variables](../variables/predefined_variables.md#variable-availability).
Alternatively, use [`trigger:project`](#triggerproject).
- For child pipelines, use [`trigger:include`](#triggerinclude).
@ -5251,7 +5251,7 @@ trigger-multi-project-pipeline:
- [Pipeline variables](../variables/index.md#cicd-variable-precedence) are not passed
to downstream pipelines by default. Use [trigger:forward](#triggerforward) to forward
these variables to downstream pipelines.
- [Job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables)
- [Job-only variables](../variables/predefined_variables.md#variable-availability)
are not available in trigger jobs.
- Environment variables [defined in the runner's `config.toml`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) are not available to trigger jobs and are not passed to downstream pipelines.
- You cannot use [`needs:pipeline:job`](#needspipelinejob) in a trigger job.
@ -5301,7 +5301,7 @@ to specify a different branch.
**Possible inputs**:
- The path to the downstream project. CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
in GitLab 15.3 and later, but not [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
in GitLab 15.3 and later, but not [job-only variables](../variables/predefined_variables.md#variable-availability).
**Example of `trigger:project`**:

9
doc/development/documentation/experiment_beta.md
View File

@ -60,6 +60,9 @@ When documenting a GitLab Duo experiment:
- Document the feature on the [GitLab Duo experiments page](../../user/gitlab_duo/experiments.md).
- Make sure you add history and status values, including any
[add-on information](styleguide/availability_details.md#gitlab-duo-pro-or-enterprise-add-on).
- For features that are part of the [Early Access Program](../early_access_program/index.md#add-a-feature-to-the-program)
in the `#developer-relations-early-access-program` Slack channel,
post a comment that mentions the feature and its status.
### Beta
@ -71,6 +74,9 @@ When a GitLab Duo experiment moves to beta:
move the content somewhere more appropriate (near other related features).
- Make sure you update the history and status values, including any
[add-on information](styleguide/availability_details.md#gitlab-duo-pro-or-enterprise-add-on).
- For features that are part of the [Early Access Program](../early_access_program/index.md#add-a-feature-to-the-program)
in the `#developer-relations-early-access-program` Slack channel,
post a comment that mentions the feature and its status.
### Generally available
@ -82,3 +88,6 @@ When a GitLab Duo feature becomes generally available:
move the content somewhere more appropriate (near other related features).
- Make sure you update the history and status values, including any
[add-on information](styleguide/availability_details.md#gitlab-duo-pro-or-enterprise-add-on).
- For features that are part of the [Early Access Program](../early_access_program/index.md#add-a-feature-to-the-program)
in the `#developer-relations-early-access-program` Slack channel,
post a comment that mentions the feature and its status.

41
doc/development/early_access_program/index.md Normal file
View File

@ -0,0 +1,41 @@
---
stage: none
group: Contributor Success
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
---
# GitLab Early Access Program
NOTE:
Last status update 2024-09-01.
These features may not be ready for production use and follow the [Experimental or Beta policy](../../policy/experiment-beta-support.md) of GitLab.
WARNING:
The GitLab Early Access Program is not operational yet. This page is in draft and in preparation for an upcoming launch.
## Features included in the GitLab Early Access Program
| Name | Status | Included date |
|---------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------|-------------|
| [GitLab Duo Merge Request Summary](../../user/project/merge_requests/duo_in_merge_requests.md#generate-a-description-by-summarizing-code-changes) | [Beta](../../policy/experiment-beta-support.md#beta) | 2024-09-01 |
| [GitLab Duo Vulnerability Resolution](../../user/application_security/vulnerabilities/index.md#vulnerability-resolution) | [Beta](../../policy/experiment-beta-support.md#beta) | 2024-09-01 |
| [GitLab Duo Discussion Summary](../../user/discussions/index.md#summarize-issue-discussions-with-duo-chat) | [Beta](../../policy/experiment-beta-support.md#beta) | 2024-09-01 |
| [GitLab Duo Issue Description Generation](../../user/gitlab_duo/experiments.md#populate-an-issue-with-issue-description-generation) | [Experiment](../../policy/experiment-beta-support.md#experiment) | 2024-09-01 |
| [GitLab Duo Code Review Summary](../../user/project/merge_requests/duo_in_merge_requests.md#summarize-a-code-review) | [Experiment](../../policy/experiment-beta-support.md#experiment) | 2024-09-01 |
| [GitLab Duo Product Analytics](../../user/analytics/analytics_dashboards.md#generate-a-custom-visualization-with-gitlab-duo) | [Experiment](../../policy/experiment-beta-support.md#experiment) | 2024-09-01 |
Would you like to use a paid feature but don't have a subscription?
You are more than welcome to [request a free trial](https://about.gitlab.com/free-trial/).
## Add a feature to the program
Create a merge request and add your feature to the [table above](#features-included-in-the-gitlab-early-access-program). Assign `@nick_vh` and `@knockfog-ext` as reviewers. In addition, post a message in the `#developer-relations-early-access-program` Slack channel for details.
<!--
## Features previously enrolled
| Name | Status | Enrolled at | Removed at |
|-----------------------------------------------------------------------------------|------------|---------------| -------------|
| | | | |
-->

5
doc/development/testing_guide/unhealthy_tests.md
View File

@ -231,7 +231,10 @@ bin/rspec --tag ~quarantine
bin/rspec --tag \~quarantine
```
Also, please add the ~"quarantine" label on the merge request.
Also, please ensure that:
1. The ~"quarantine" label is present on the merge request.
1. The MR description mentions the flaky test issue with [the usual terms to link a merge request to an issue](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/8b8621ba5c0db3c044a771ebf84887a0a07353b3/triage/triage/related_issue_finder.rb#L8-18).
Note that we [should not quarantine a shared example/context](https://gitlab.com/gitlab-org/gitlab/-/issues/404388), and [we cannot quarantine a call to `it_behaves_like` or `include_examples`](https://github.com/rspec/rspec-core/pull/2307#issuecomment-236006902):

57
doc/install/requirements.md
View File

@ -55,48 +55,31 @@ In certain circumstances, GitLab might run in a
PostgreSQL is the only supported database and is bundled with the Linux package.
You can also use an [external PostgreSQL database](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server).
The server running PostgreSQL should have a certain amount of storage available, though the exact amount
[depends on the number of users](../administration/reference_architectures/index.md). For:
Depending on the [number of users](../administration/reference_architectures/index.md),
the PostgreSQL server should have:
- Most GitLab self-managed instances, at least 5 to 10 GB of storage available.
- GitLab self-managed instance at the Ultimate tier, at least 12 GB of storage available, because 1 GB of vulnerability
data must be imported.
- For most GitLab instances, at least 5 to 10 GB of storage
- For GitLab Ultimate, at least 12 GB of storage
(1 GB of vulnerability data must be imported)
You should use the versions of PostgreSQL specified in the following table for your version of GitLab because these were
used for development and testing:
For the following versions of GitLab, use these PostgreSQL versions:
| GitLab version | Minimum PostgreSQL version<sup>1</sup> | Maximum PostgreSQL version<sup>2</sup> |
|:---------------|:---------------------------------------|:---------------------------------------|
| 15.x | 12.10 | 13.x (14.x<sup>3</sup>) |
| 16.x | 13.6 | 15.x<sup>4</sup> |
| 17.x | 14.9 | 15.x<sup>4</sup> |
| GitLab version | Minimum PostgreSQL version | Maximum PostgreSQL version |
| -------------- | -------------------------- | -------------------------- |
| 17.x | 14.9 | 15.x |
| 16.x | 13.6 | 15.x ([tested against GitLab 16.1 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119344)) |
| 15.x | 12.10 | 14.x ([tested against GitLab 15.11 only](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114624)), 13.x |
**Footnotes:**
Minor PostgreSQL releases [include only bug and security fixes](https://www.postgresql.org/support/versioning/).
Always use the latest minor version to avoid known issues in PostgreSQL.
For more information, see [issue 364763](https://gitlab.com/gitlab-org/gitlab/-/issues/364763).
1. PostgreSQL minor release upgrades (for example 14.8 to 14.9) [include only bug and security fixes](https://www.postgresql.org/support/versioning/).
Patch levels in this table are not prescriptive. Always deploy the most recent patch level
to avoid [known bugs in PostgreSQL that might be triggered by GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/364763).
1. If you want to run a later major release of PostgreSQL than the specified minimum
[check if a more recent version shipped with Linux package (Omnibus) GitLab](http://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html).
`postgresql-new` is a later version that's definitely supported.
1. PostgreSQL 14.x [tested against GitLab 15.11 only](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114624).
1. [Tested against GitLab 16.1 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119344).
To use a later major version of PostgreSQL than specified, check if a
[later version is bundled with the Linux package](http://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html).
You must also ensure the following extensions are loaded into every GitLab database.
You must also ensure some extensions are loaded into every GitLab database.
For more information, see [managing PostgreSQL extensions](postgresql_extensions.md).
| Extension | Minimum GitLab version |
| ------------ | ---------------------- |
| `pg_trgm` | 8.6 |
| `btree_gist` | 13.1 |
| `plpgsql` | 11.7 |
The following managed PostgreSQL services are known to be incompatible and should not be used:
| GitLab version | Managed service |
|----------------|-------------------------------------------------------|
| 14.4+ | Amazon Aurora (see [14.4.0](../update/versions/gitlab_14_changes.md#1440)) |
#### GitLab Geo
If you're using [GitLab Geo](../administration/geo/index.md), we strongly recommend running instances installed by using the Linux package or using
@ -297,10 +280,10 @@ GitLab supports the following web browsers:
- [Apple Safari](https://www.apple.com/safari/)
- [Microsoft Edge](https://www.microsoft.com/en-us/edge?form=MA13QK)
GitLab supports the:
GitLab supports:
- Current and previous major versions of these browsers
- Current minor version of a supported major version
- The current and earlier major versions of these browsers
- The current minor version of a supported major version
Running GitLab with JavaScript disabled in these browsers is not supported.

2
doc/update/versions/gitlab_17_changes.md
View File

@ -197,7 +197,7 @@ a certificate signed with an RSA key can use RSA-2048 but not RSA-1024. GitLab
will fail to connect to a service that uses a certificate signed with insufficient
bits with a `certificate key too weak` error message.
Check the [GitLab documentation on securing your installation](../../security/index.md).
Check the [GitLab documentation on securing your installation](../../security/index.md)
for more details.
## 17.4.0

34
doc/user/custom_roles.md
View File

@ -114,7 +114,7 @@ Prerequisites:
1. Modify the role as needed.
1. Select **Save role** to update the role.
### GitLab self-managed and GitLab Dedicated
### GitLab self-managed
Prerequisites:
@ -271,6 +271,38 @@ This does not apply when the user's custom role only has the `read_code` permiss
enabled. Guest users with that specific permission only are not considered billable users
and do not use a seat.
## Assign a custom role to an invited group
> - Support for custom roles for invited groups [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/443369) in GitLab 17.4 behind a feature flag named `assign_custom_roles_to_group_links_sm`. Disabled by default.
FLAG:
The availability of this feature is controlled by a feature flag. For more information, see the history.
When a group is invited to another group with a custom role, the following rules determine each user's custom permissions in the new group:
- When a user has a custom permission in one group with a base access level that is the same or higher than the default role in the other group, the user's maximum role is the default role. That is, the user is granted the lower of the two access levels.
- When a user is invited with a custom permission with the same base access level as their original group, the user is always granted the custom permission from their original group.
For example, let's say we have 5 users in Group A, and they are assigned the following roles:
- User A: Guest role
- User B: Guest role + `read_code` custom permission
- User C: Guest role + `read_vulnerability` custom permission
- User D: Developer role
- User E: Developer + `admin_vulnerability` custom permission
Group B invites Group A. The following table shows the maximum role that each the users in Group A will have in Group B:
| Scenario | User A | User B | User C | User D | User E |
|----------------------------------------------------------------|--------|---------------------|------------------------------|-----------|-----------------------------------|
| Group B invites Group A with Guest | Guest | Guest | Guest | Guest | Guest |
| Group B invites Group A with Guest + `read_code` | Guest | Guest + `read_code` | Guest + `read_vulnerability` | Guest | Guest |
| Group B invites Group A with Guest + `read_vulnerability` | Guest | Guest + `read_code` | Guest + `read_vulnerability` | Guest | Guest |
| Group B invites Group A with Developer | Guest | Guest + `read_code` | Guest + `read_vulnerability` | Developer | Developer |
| Group B invites Group A with Developer + `admin_vulnerability` | Guest | Guest + `read_code` | Guest + `read_vulnerability` | Developer | Developer + `admin_vulnerability` |
When User C is invited to Group B with the same default role (Guest), but different custom permissions with the same base access level (`read_code` and `read_vulnerability`), User C retains the custom permission from Group A (`read_vulnerability`).
## Supported objects
You can assign custom roles and permissions to the following:

27
doc/user/duo_workflow/index.md
View File

@ -23,6 +23,7 @@ GitLab Duo Workflow, as part of your IDE, takes the information you provide
and uses AI to walk you through an implementation plan.
For the first release, there is only one supported Workflow: write or update code to fix a broken pipeline on a merge request.
You can do this from VS Code or by running a cURL command.
## Prerequisites
@ -92,6 +93,32 @@ To use GitLab Duo Workflow:
- Merge request ID: In GitLab, the ID is in the merge request URL.
- Project ID: In GitLab, the ID is on the project overview page. In the upper-right corner, select the vertical ellipsis (**{ellipsis_v}**) to view it.
## Use cURL to run GitLab Duo Workflow against a CI/CD pipeline
Instead of running GitLab Workflow in VS Code, you can use a cURL command. See
[the handbook](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/duo_workflow/#with-remote-ci-pipeline-execution) for details.
1. Create a personal access token with the `api` scope, or create an OAuth access token with the `ai_workflows` scope.
1. Start GitLab Workflow in a CI/CD pipeline by using the following cURL request.
```shell
curl POST --verbose \
--header 'Authorization: Bearer $YOUR_GITLAB_PAT' \
--header 'Content-Type: application/json' \
--data '{
"project_id": "$PROJECT_ID_FOR_RUNNING_WORKFLOW_AGAINST",
"start_workflow": true,
"goal": "Fix the pipeline for merge request X in project Y."
}' \
--location 'https://gitlab.com/api/v4/ai/duo_workflows/workflows'
```
The response should be the pipeline ID. To view the pipeline execution, go to:
```http
https://gitlab.com/$namespace/$project/-/pipelines/$pipeline_id
```
## The context Duo Workflow is aware of
GitLab Duo Workflow is aware of the context you're working in, specifically:

16
doc/user/gitlab_duo/turn_on_off.md
View File

@ -87,6 +87,22 @@ To run a health check:
1. Select **GitLab Duo**.
1. On the upper-right corner, select **Run health check**.
### Health check probes
The health check executes the following probes to check if your instance meets the requirements
to use GitLab Duo. If the health check fails any of these probes, users might not be able to use
GitLab Duo features in your instance.
- **Network:** Checks that your instance can connect to `customers.gitlab.com` and `cloud.gitlab.com`. If your
instance cannot connect to either destination, ensure that your firewall or proxy server settings [allow connection](#configure-gitlab-duo-on-a-self-managed-instance) to these destinations.
- **Synchronization:** Checks if your subscription:
- Has been activated with an activation code and can be synchronized with `customers.gitlab.com`.
- Has correct access credentials.
- Has been synchronized recently. If it hasn't or the access credentials are missing or expired, you can
[manually synchronize](../../subscriptions/self_managed/index.md#manually-synchronize-subscription-data) your subscription data.
- **System exchange:** Checks if Code Suggestions can be used in your instance. If the system
exchange probe fails, users might not be able to use GitLab Duo features.
## Turn off GitLab Duo features
You can turn off GitLab Duo for a group, project, or instance.

2
doc/user/project/members/sharing_projects_groups.md
View File

@ -123,7 +123,7 @@ To invite a group to a project:
1. Select **Manage > Members**.
1. Select **Invite a group**.
1. In the **Select a group to invite** list, select the group you want to invite.
1. Select the highest [role](../../permissions.md) for users in the group.
1. Select the highest [role](../../permissions.md) or [custom role](../../custom_roles.md#assign-a-custom-role-to-an-invited-group) for users in the group.
1. Optional. Select an **Access expiration date**.
From that date onward, the invited group can no longer access the project.
1. Select **Invite**.

21
doc/user/project/pages/getting_started_part_one.md
View File

@ -15,6 +15,8 @@ according to your intended website's URL.
## GitLab Pages default domain names
> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163523) unique domain URLs to be shorter in GitLab 17.4.
If you use your own GitLab instance to deploy your site with GitLab Pages, verify your Pages
wildcard domain with your sysadmin. This guide is valid for any GitLab instance, provided that you
replace the Pages wildcard domain on GitLab.com (`*.gitlab.io`) with your own.
@ -40,16 +42,17 @@ Pages domains are `*.gitlab.io`.
When **Use unique domain** setting is enabled, all URLs
are flattened with the following structure:
| Type of GitLab Pages | Example path of a project in GitLab | Website URL |
| -------------------- | ------------ | ----------- |
| User pages | `username/username.example.io` | `http(s)://username-example-io-username.example.io` |
| Group pages | `acmecorp/acmecorp.example.io` | `http(s)://acmecorp-example-io-acmecorp-uniqueid.example.io` |
| Project pages owned by a user | `username/my-website` | `https://my-website-username-uniqueid.gitlab.io/` |
| Project pages owned by a group | `acmecorp/webshop` | `http(s)://webshop-acmecorp-uniqueid.example.io/`|
| Project pages owned by a subgroup | `acmecorp/documentation/product-manual` | `http(s)://product-manual-documentation-acmecorp-uniqueid.example.io/`|
| Type of GitLab Pages | Example path of a project in GitLab | Website URL |
| --------------------------------- | --------------------------------------- | ----------- |
| User pages | `username/username.example.io` | `http(s)://username-example-io-123456.example.io` |
| Group pages | `acmecorp/acmecorp.example.io` | `http(s)://acmecorp-example-io-123456.example.io` |
| Project pages owned by a user | `username/my-website` | `https://my-website-123456.gitlab.io/` |
| Project pages owned by a group | `acmecorp/webshop` | `http(s)://webshop-123456.example.io/` |
| Project pages owned by a subgroup | `acmecorp/documentation/product-manual` | `http(s)://product-manual-123456.example.io/` |
The `unique_id` portion of the URL is an alphanumeric string. For example, if the `unique_id` is `30bae2547a50der6ed7d9a08d417a33525a5c4dc6fdd68`, the last example would be
`http(s)://product-manual-documentation-acmecorp-30bae2547a50der6ed7d9a08d417a33525a5c4dc6fdd68.example.io/`.
`123456` in the example URLs is a six-character unique ID.
For example, if the unique ID is `f85695`, the last example is
`http(s)://product-manual-f85695.example.io/`.
WARNING:
There are some known [limitations](introduction.md#subdomains-of-subdomains)

9
doc/user/project/pages/index.md
View File

@ -164,6 +164,7 @@ To ensure each project uses different cookies, enable the Pages [unique domains]
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9347) in GitLab 15.9 [with a flag](../../../administration/feature_flags.md) named `pages_unique_domain`. Disabled by default.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/388151) in GitLab 15.11.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122229) in GitLab 16.3.
> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163523) unique domain URLs to be shorter in GitLab 17.4.
By default, every new project uses pages unique domain. This is to avoid projects on the same group
to share cookies.
@ -172,9 +173,11 @@ The project maintainer can disable this feature on:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Deploy > Pages**.
1. Deselect the **Use unique domain** checkbox.
1. Clear the **Use unique domain** checkbox.
1. Select **Save changes**.
For example URLs, see [GitLab Pages default domain names](getting_started_part_one.md#gitlab-pages-default-domain-names).
## Expiring deployments
DETAILS:
@ -256,14 +259,14 @@ The value of `pages.path_prefix` is:
Consider a project such as `https://gitlab.example.com/namespace/project`. By default, its main Pages deployment can be accessed through:
- When using a [unique domain](#unique-domains): `https://project-namespace-uniqueid.gitlab.io/`.
- When using a [unique domain](#unique-domains): `https://project-namespace-123456.gitlab.io/`.
- When not using a unique domain: `https://namespace.gitlab.io/project`.
If a `pages.path_prefix` is configured to the project branch names,
like `path_prefix = $CI_COMMIT_BRANCH`, and there's a
branch named `username/testing_feature`, this extra Pages deployment would be accessible through:
- When using a [unique domain](#unique-domains): `https://project-namespace-uniqueid.gitlab.io/username-testing-feature`.
- When using a [unique domain](#unique-domains): `https://project-namespace-123456.gitlab.io/username-testing-feature`.
- When not using a unique domain: `https://namespace.gitlab.io/project/username-testing-feature`.
### Enable multiple deployments

9
lib/gitlab/ci/pipeline/chain/command.rb
View File

@ -14,11 +14,16 @@ module Gitlab
:chat_data, :allow_mirror_update, :bridge, :content, :dry_run, :logger, :execution_policy_dry_run,
# These attributes are set by Chains during processing:
:config_content, :yaml_processor_result, :workflow_rules_result, :pipeline_seed,
:pipeline_config, :execution_policy_pipelines, :partition_id,
keyword_init: true
:pipeline_config, :execution_policy_pipelines, :partition_id
) do
include Gitlab::Utils::StrongMemoize
def initialize(params = {})
params.each do |key, value|
self[key] = value
end
end
def dry_run?
dry_run || execution_policy_dry_run
end

15
locale/gitlab.pot
View File

@ -2228,30 +2228,15 @@ msgstr ""
msgid "AIAgent|Your agent's system prompt will be applied to the chat input."
msgstr ""
msgid "AIPoweredSM|AI-powered features"
msgstr ""
msgid "AIPoweredSM|By enabling this feature, you agree to the %{link_start}GitLab Testing Agreement%{link_end}."
msgstr ""
msgid "AIPoweredSM|Disable %{link_start}direct connections%{link_end} for this instance."
msgstr ""
msgid "AIPoweredSM|Disable direct connections for Code Suggestions"
msgstr ""
msgid "AIPoweredSM|Enable %{link_start}AI-powered features%{link_end} for this instance."
msgstr ""
msgid "AIPoweredSM|Enable GitLab Duo features"
msgstr ""
msgid "AIPoweredSM|Enable experiment and beta AI-powered features"
msgstr ""
msgid "AIPoweredSM|Enforce Duo features setting for all subgroups"
msgstr ""
msgid "AISummary|Generates a summary of all comments"
msgstr ""

33
spec/frontend/lib/utils/datetime/date_calculation_utility_spec.js
View File

@ -9,6 +9,8 @@ import {
differenceInMinutes,
getMonthsBetweenDates,
newDate,
convertNanoToMs,
convertMsToNano,
} from '~/lib/utils/datetime/date_calculation_utility';
import { useFakeDate } from 'helpers/fake_date';
@ -188,3 +190,34 @@ describe('getMonthsBetweenDates', () => {
]);
});
});
describe('convertNanoToMs', () => {
it('converts nanoseconds to milliseconds correctly', () => {
expect(convertNanoToMs(1e6)).toBe(1);
expect(convertNanoToMs(5e6)).toBe(5);
expect(convertNanoToMs(1e9)).toBe(1000);
});
it('handles zero', () => {
expect(convertNanoToMs(0)).toBe(0);
});
it('handles fractional nanoseconds', () => {
expect(convertNanoToMs(1567000)).toBe(1.567);
});
});
describe('convertMsToNano', () => {
it('converts milliseconds to nanoseconds correctly', () => {
expect(convertMsToNano(5)).toBe(5e6);
expect(convertMsToNano(1234)).toBe(1234000000);
});
it('handles zero', () => {
expect(convertMsToNano(0)).toBe(0);
});
it('handles fractional milliseconds', () => {
expect(convertMsToNano(1.5)).toBe(1500000);
});
});

2
spec/lib/gitlab/relative_positioning/range_spec.rb
View File

@ -95,7 +95,7 @@ RSpec.describe Gitlab::RelativePositioning::Range do
item_c = position_struct.new(150, :z, true)
item_d = position_struct.new(050, :w, true)
item_e = position_struct.new(250, :r, true)
item_f = position_struct.new(nil, nil, false)
item_f = position_struct.new(positioned?: false)
item_ax = position_struct.new(100, :not_x, true)
item_bx = position_struct.new(200, :not_y, true)

3
spec/services/merge_requests/unstick_locked_merge_requests_service_spec.rb
View File

@ -152,7 +152,8 @@ RSpec.describe MergeRequests::UnstickLockedMergeRequestsService, :clean_gitlab_r
expect(Gitlab::MergeRequests::LockedSet.all).to be_empty
end
it 'logs updated stuck merge job ids and errored MRs' do
it 'logs updated stuck merge job ids and errored MRs',
quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/477967' do
mr_1 = create(
:merge_request,
:locked,

2
spec/spec_helper.rb
View File

@ -21,8 +21,6 @@ SimpleCovEnv.start!
require './spec/crystalball_env'
CrystalballEnv.start!
require_relative 'support/struct_with_kwargs'
ENV["RAILS_ENV"] = 'test'
ENV["IN_MEMORY_APPLICATION_SETTINGS"] = 'true'
ENV["RSPEC_ALLOW_INVALID_URLS"] = 'true'

1
spec/support/rspec.rb
View File

@ -3,7 +3,6 @@
require_relative 'rake'
require_relative 'rspec_order'
require_relative 'rspec_run_time'
require_relative 'struct_with_kwargs'
require_relative 'system_exit_detected'
require_relative 'helpers/stub_configuration'
require_relative 'helpers/stub_metrics'

38
spec/support/struct_with_kwargs.rb
View File

@ -1,38 +0,0 @@
# frozen_string_literal: true
# Detect incompatbilities between Ruby 3.1 and Ruby 3.2+ in the cases where
# Struct.new is missing `keyword_init: true` and a Hash is passed.
#
# See https://gitlab.com/gitlab-org/gitlab/-/issues/474743
module StructWithKwargs
# Excluding structs we don't own and cannot patch.
EXCLUDE = %w[
Aws::S3::EndpointParameters
].freeze
def self.check?(klass)
!EXCLUDE.include?(klass.name) # rubocop:disable Rails/NegateInclude -- Rails is not always available.
end
module Patch
def new(*args, **kwargs)
return super if kwargs[:keyword_init]
super.prepend KwargsCheck
end
end
module KwargsCheck
def initialize(*args, **kwargs, &block)
if args.empty? && kwargs.any? && StructWithKwargs.check?(self.class)
raise <<~MESSAGE
Passing only keyword arguments to #{self.class}#initialize will behave differently from Ruby 3.2. Please pass `keyword_init: true` to `Struct` constructor or use a Hash literal like .new({k: v}) instead of .new(k: v).
MESSAGE
end
super
end
end
end
Struct.singleton_class.prepend StructWithKwargs::Patch

71
spec/support_specs/struct_with_kwargs_spec.rb
View File

@ -1,71 +0,0 @@
# frozen_string_literal: true
require 'fast_spec_helper'
require 'rspec-parameterized'
RSpec.describe StructWithKwargs, feature_category: :tooling do
let(:const_name) { 'TEST_STRUCT' }
before do
stub_const(const_name, struct)
end
context 'with lack of keyword_init: true' do
subject(:struct) { Struct.new(:foo) }
it { is_expected.to include(described_class::KwargsCheck) }
it 'accepts plain values' do
expect(struct.new(23)).to have_attributes(foo: 23)
end
it 'accepts hash' do
expect(struct.new({ foo: 23 })).to have_attributes(foo: { foo: 23 })
end
it 'raises with kwargs' do
expect { struct.new(foo: 23) }
.to raise_error(RuntimeError, /Passing only keyword arguments to TEST_STRUCT#initialize/)
end
context 'and also positional arguments' do
subject(:struct) { Struct.new(:foo, :bar) }
it 'accepts mix of plain and hash' do
expect(struct.new(1, x: 23)).to have_attributes(foo: 1, bar: { x: 23 })
end
it 'raises with kwargs only' do
expect { struct.new(foo: 23, bar: 42) }
.to raise_error(RuntimeError, /Passing only keyword arguments to TEST_STRUCT#initialize/)
end
end
end
context 'with Struct.new(..., keyword_init: true)' do
subject(:struct) { Struct.new(:foo, keyword_init: true) }
it { is_expected.not_to include(described_class::KwargsCheck) }
it 'accepts kwargs or hash', :aggregate_failures do
expect(struct.new(foo: 23)).to have_attributes(foo: 23)
expect(struct.new({ foo: 23 })).to have_attributes(foo: 23)
end
end
describe 'excludes' do
where(:exclude) { described_class::EXCLUDE }
with_them do
let(:const_name) { exclude }
subject(:struct) { Struct.new(:a) }
it { is_expected.to include(described_class::KwargsCheck) }
it 'accepts hash' do
expect(struct.new(a: 23)).to have_attributes(a: 23)
end
end
end
end