diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index 7b37a9c8b255e0680ada79fa8d56204643915240..36519561d6cc87adaf783960bd6c6e03bea1ec3c 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -70,9 +70,6 @@ For runners to work with caches efficiently, you must do one of the following:
## Use multiple caches
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32814) in GitLab 13.10.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321877), in GitLab 13.12.
-
You can have a maximum of four caches:
```yaml
diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md
index 4a820de4d0f0dc4924d1b901ec6810eba0cb5e35..3f74d2cf67b6139e3000630fcf73768111f00e5c 100644
--- a/doc/ci/directed_acyclic_graph/index.md
+++ b/doc/ci/directed_acyclic_graph/index.md
@@ -10,9 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063) in GitLab 12.2.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/206902) in GitLab 12.10.
-
A [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph) can be
used in the context of a CI/CD pipeline to build relationships between jobs such that
execution is performed in the quickest possible manner, regardless how stages may
@@ -84,10 +81,6 @@ are certain use cases that you may need to work around. For more information, ch
## Needs Visualization
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215517) in GitLab 13.1 as a [Beta feature](../../policy/experiment-beta-support.md#beta).
-> - It became a [standard feature](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38517) in 13.3.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52208) in GitLab 13.9.
-
The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph displays all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
To see the needs visualization, select **Needs** when viewing a pipeline that uses the `needs` keyword.
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index 098b6b8d55ae0eb9f402eed3e362689037adf42f..7476ef15e438f6e17582a244ac2f13b4fc30376a 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -98,9 +98,6 @@ For example:
## Job name limitations
-> - [Enabled 255-character job length on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/342800) in GitLab 14.5.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/344665) in GitLab 14.10. [Feature flag `ci_validate_job_length`](https://gitlab.com/gitlab-org/gitlab/-/issues/344665) removed.
-
You can't use these keywords as job names:
- `image`
@@ -177,10 +174,6 @@ One or more `: [...]`, `X Y`, `X/Y`, or `X\Y` sequences are removed from the **e
of job names only. Matching substrings found at the beginning or in the middle of
job names are not removed.
-In [GitLab 13.8 and earlier](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52644),
-the regular expression is `\d+[\s:\/\\]+\d+\s*`. [Feature flag](../../user/feature_flags.md)
-removed in [GitLab 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/322080).
-
## Hide jobs
To temporarily disable a job without deleting it from the configuration
@@ -266,8 +259,6 @@ In this example:
## Specifying variables when running manual jobs
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30485) in GitLab 12.2.
-
When running manual jobs you can supply additional job specific variables.
You can do this from the job page of the manual job you want to run with
@@ -301,7 +292,6 @@ For example, if you start rolling out new code and:
## Expand and collapse job log sections
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/14664) in GitLab 12.0.
> - Support for output of multi-line command bash shell output [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3486) in GitLab 16.5 behind the [GitLab Runner feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html), `FF_SCRIPT_SECTIONS`.
Job logs are divided into sections that can be collapsed or expanded. Each section displays
@@ -316,8 +306,6 @@ In the following example:
### Custom collapsible sections
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/14664) in GitLab 12.0.
-
You can create [collapsible sections in job logs](#expand-and-collapse-job-log-sections)
by manually outputting special codes
that GitLab uses to determine what sections to collapse:
@@ -404,8 +392,6 @@ To remove `echo` statements from the job output, you can move the job contents t
### Pre-collapse sections
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198413) in GitLab 13.5.
-
You can make the job log automatically collapse collapsible sections by adding the `collapsed` option to the section start.
Add `[collapsed=true]` after the section name and before the `\r`. The section end marker
remains unchanged:
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index e5d68de0ca36a7413bf84f509ce461b897c88be8..936595c82202099ad9109442dbf7e8ba80ebda48 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -333,8 +333,6 @@ You can use the `$` character for both variables and paths. For example, if the
### Reuse rules in different jobs
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322992) in GitLab 14.3.
-
Use [`!reference` tags](../yaml/yaml_optimization.md#reference-tags) to reuse rules in different
jobs. You can combine `!reference` rules with regular job-defined rules:
@@ -569,8 +567,6 @@ deploystacks: [vultr, data]
### Select different runner tags for each parallel matrix job
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/239737) in GitLab 14.1.
-
You can use variables defined in `parallel: matrix` with the [`tags`](../yaml/index.md#tags)
keyword for dynamic runner selection:
diff --git a/doc/ci/lint.md b/doc/ci/lint.md
index 97f18a7783c53c6b9c38f163e5c341a59171af47..335ac5dcb8542ea940b010a5b699abced39c2c24 100644
--- a/doc/ci/lint.md
+++ b/doc/ci/lint.md
@@ -36,8 +36,6 @@ To check CI/CD configuration with the CI lint tool:
## Simulate a pipeline
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229794) in GitLab 13.3.
-
You can simulate the creation of a GitLab CI/CD pipeline to find more complicated issues,
including problems with [`needs`](yaml/index.md#needs) and [`rules`](yaml/index.md#rules)
configuration. A simulation runs as a Git `push` event on the default branch.
diff --git a/doc/ci/pipeline_editor/index.md b/doc/ci/pipeline_editor/index.md
index cc091e91fee88b1d1540933aa50ee81ea8cbefad..36798628954ae66e46e54b1c9b6a1486fa050ab6 100644
--- a/doc/ci/pipeline_editor/index.md
+++ b/doc/ci/pipeline_editor/index.md
@@ -10,9 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4540) in GitLab 13.8.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/270059) in GitLab 13.10.
-
The pipeline editor is the primary place to edit the GitLab CI/CD configuration in
the `.gitlab-ci.yml` file in the root of your repository. To access the editor, go to **Build > Pipeline editor**.
@@ -27,9 +24,6 @@ From the pipeline editor page you can:
- View the [full configuration](#view-full-configuration), which displays the configuration with any configuration from `include` added.
- [Commit](#commit-changes-to-ci-configuration) the changes to a specific branch.
-In GitLab 13.9 and earlier, you must already have [a `.gitlab-ci.yml` file](../quick_start/index.md#create-a-gitlab-ciyml-file)
-on the default branch of your project to use the editor.
-
## Validate CI configuration
As you edit your pipeline configuration, it is continually validated against the GitLab CI/CD
@@ -83,10 +77,6 @@ for review.
## Visualize CI configuration
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241722) in GitLab 13.5.
-> - [Moved to **Build > Pipeline editor**](https://gitlab.com/gitlab-org/gitlab/-/issues/263141) in GitLab 13.7.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/290117) in GitLab 13.12.
-
To view a visualization of your `.gitlab-ci.yml` configuration, in your project,
go to **Build > Pipeline editor**, and then select the **Visualize** tab. The
visualization shows all stages and jobs. Any [`needs`](../yaml/index.md#needs)
@@ -104,8 +94,6 @@ each job depends only on the previous stage being completed successfully.
## View full configuration
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/246801) in GitLab 13.9.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/301103) in GitLab 13.12.
> - **View merged YAML** tab [renamed to **Full configuration**](https://gitlab.com/gitlab-org/gitlab/-/issues/377404) in GitLab 16.0.
To view the fully expanded CI/CD configuration as one combined file, go to the
diff --git a/doc/ci/pipelines/downstream_pipelines.md b/doc/ci/pipelines/downstream_pipelines.md
index 92a9788287cdbb77d7a667cf5113f8450e48d572..2add977c036b2b1885d6ae545a500effb61f0568 100644
--- a/doc/ci/pipelines/downstream_pipelines.md
+++ b/doc/ci/pipelines/downstream_pipelines.md
@@ -41,9 +41,6 @@ Child pipelines:
### Nested child pipelines
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29651) in GitLab 13.4.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243747) in GitLab 13.5.
-
Parent and child pipelines have a maximum depth of two levels of child pipelines.
A parent pipeline can trigger many child pipelines, and these child pipelines can trigger
@@ -148,8 +145,6 @@ job3:
### Use a child pipeline configuration file in a different project
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) in GitLab 13.5.
-
You can use [`include:project`](../yaml/index.md#includeproject) in a trigger job
to trigger child pipelines with a configuration file in a different project:
@@ -314,8 +309,6 @@ trigger_pipeline:
## View a downstream pipeline
-> - Hover behavior for pipeline cards [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) in GitLab 13.2.
-
In the [pipeline graph view](index.md#view-full-pipeline-graph), downstream pipelines display
as a list of cards on the right of the graph. From this view, you can:
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 1b52d83b84c3f4cafe8d0a4877fd9ea368d7fdaa..b919df137133c6f8532ebf51dc3cf13c1addcef7 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -116,17 +116,15 @@ A link to the latest pipeline for the last commit of a given branch is available
`/project/-/pipelines/[branch]/latest`. Also, `/project/-/pipelines/latest` redirects
you to the latest pipeline for the last commit on the project's default branch.
-[Starting in GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/215367),
-you can filter the pipeline list by:
+You can filter the pipeline list by:
- Trigger author
- Branch name
-- Status ([GitLab 13.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
-- Tag ([GitLab 13.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
-- Source ([GitLab 14.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/338347))
+- Status
+- Tag
+- Source
-[Starting in GitLab 14.2](https://gitlab.com/gitlab-org/gitlab/-/issues/26621), you can change the
-pipeline column to display the pipeline ID or the pipeline IID.
+You can change the pipeline column to display the pipeline ID or the pipeline IID.
If you use VS Code to edit your GitLab CI/CD configuration, the
[GitLab Workflow VS Code extension](../../editor_extensions/visual_studio_code/index.md) helps you
@@ -154,8 +152,6 @@ The pipeline now executes the jobs as configured.
#### Prefill variables in manual pipelines
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) in GitLab 13.7.
-
You can use the [`description` and `value`](../yaml/index.md#variablesdescription)
keywords to [define pipeline-level (global) variables](../variables/index.md#define-a-cicd-variable-in-the-gitlab-ciyml-file)
that are prefilled when running a pipeline manually. Use the description to explain
@@ -223,8 +219,6 @@ variables:
### Run a pipeline by using a URL query string
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24146) in GitLab 12.5.
-
You can use a query string to pre-populate the **Run Pipeline** page. For example, the query string
`.../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar` pre-populates the
**Run Pipeline** page with:
@@ -283,8 +277,6 @@ pipelines.
### Delete a pipeline
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24851) in GitLab 12.7.
-
Users with the Owner role for a project can delete a pipeline
by selecting the pipeline in the **Build > Pipelines** to get to the **Pipeline Details**
page, then selecting **Delete**.
@@ -334,8 +326,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9045) in GitLab 12.8.
-
You can trigger a pipeline in your project whenever a pipeline finishes for a new
tag in a different project.
@@ -422,8 +412,6 @@ GitLab capitalizes the stages' names in the pipeline graphs.
### View full pipeline graph
-> - Visualization improvements [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276949) in GitLab 13.11.
-
The [pipeline details page](#view-pipelines) displays the full pipeline graph of
all the jobs in the pipeline.
@@ -446,10 +434,6 @@ pipeline graph. The remaining jobs still run as usual. To see the jobs:
### View job dependencies in the pipeline graph
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/298973) in GitLab 13.12.
-> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/328538) in GitLab 14.0.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/328538) in GitLab 14.2.
-
To arrange jobs in the pipeline graph based on their [`needs`](../yaml/index.md#needs)
dependencies, select **Job dependencies** in the **Group jobs by** section. This option
is available for pipelines with 3 or more jobs with `needs` job dependencies.
@@ -480,7 +464,7 @@ be found when you go to:
- The pipelines index page.
- A single commit page.
- A merge request page.
-- The [pipeline editor](../pipeline_editor/index.md), [in GitLab 14.5](https://gitlab.com/gitlab-org/gitlab/-/issues/337514) and later.
+- The [pipeline editor](../pipeline_editor/index.md).
Pipeline mini graphs allow you to see all related jobs for a single commit and the net result
of each stage of your pipeline. This allows you to quickly see what failed and
diff --git a/doc/ci/triggers/index.md b/doc/ci/triggers/index.md
index 90650b536dff45c2808074dc8e82dbd677f9d05c..bf271ca1c9027368400389f13e0ddf1544a482fb 100644
--- a/doc/ci/triggers/index.md
+++ b/doc/ci/triggers/index.md
@@ -133,9 +133,6 @@ Replace:
#### Access webhook payload
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31197) in GitLab 13.9.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321027) in GitLab 13.11.
-
If you trigger a pipeline by using a webhook, you can access the webhook payload with
the `TRIGGER_PAYLOAD` [predefined CI/CD variable](../variables/predefined_variables.md).
The payload is exposed as a [file-type variable](../variables/index.md#use-file-type-cicd-variables),
diff --git a/doc/ci/yaml/includes.md b/doc/ci/yaml/includes.md
index 2d278166b481c418ecdb0c8e81b6ddaca0d46b29..c3ba168dc8395c651b26062a0ea0eee65dc66feb 100644
--- a/doc/ci/yaml/includes.md
+++ b/doc/ci/yaml/includes.md
@@ -302,8 +302,6 @@ default:
### Use nested includes with duplicate `includes` entries
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/28987) in GitLab 14.8
-
Nested includes can include the same configuration file. The duplicate configuration
file is included multiple times, but the effect is the same as if it was only
included once.
@@ -365,29 +363,20 @@ smoke-test-job:
## Use variables with `include`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/284883) in GitLab 13.8.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/294294) in GitLab 13.9.
-> - [Support for project, group, and instance variables added](https://gitlab.com/gitlab-org/gitlab/-/issues/219065) in GitLab 14.2.
-> - [Support for pipeline variables added](https://gitlab.com/gitlab-org/gitlab/-/issues/337633) in GitLab 14.5.
-
In `include` sections in your `.gitlab-ci.yml` file, you can use:
- [Project variables](../variables/index.md#for-a-project).
- [Group variables](../variables/index.md#for-a-group).
- [Instance variables](../variables/index.md#for-an-instance).
- Project [predefined variables](../variables/predefined_variables.md) (`CI_PROJECT_*`).
-- In GitLab 14.2 and later, the `$CI_COMMIT_REF_NAME` [predefined variable](../variables/predefined_variables.md).
-
- When used in `include`, the `CI_COMMIT_REF_NAME` variable returns the full
- ref path, like `refs/heads/branch-name`. In `include:rules`, you might need to use
- `if: $CI_COMMIT_REF_NAME =~ /main/` (not `== main`). This behavior is resolved in GitLab 14.5.
-
-In GitLab 14.5 and later, you can also use:
-
- [Trigger variables](../triggers/index.md#pass-cicd-variables-in-the-api-call).
- [Scheduled pipeline variables](../pipelines/schedules.md#add-a-pipeline-schedule).
- [Manual pipeline run variables](../pipelines/index.md#run-a-pipeline-manually).
- The `CI_PIPELINE_SOURCE` and `CI_PIPELINE_TRIGGERED` [predefined variables](../variables/predefined_variables.md).
+- The `$CI_COMMIT_REF_NAME` [predefined variable](../variables/predefined_variables.md).
+
+ When used in `include`, the `CI_COMMIT_REF_NAME` variable returns the full
+ ref path, like `refs/heads/branch-name`.
For example:
@@ -406,10 +395,6 @@ see this [CI/CD variable demo](https://youtu.be/4XR8gw3Pkos).
## Use `rules` with `include`
-> - Introduced in GitLab 14.2 [with a flag](../../administration/feature_flags.md) named `ci_include_rules`. Disabled by default.
-> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) in GitLab 14.3.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) in GitLab 14.4. Feature flag `ci_include_rules` removed.
-> - Support for `exists` keyword [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/341511) in GitLab 14.5.
> - Support for `needs` job dependency [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345377) in GitLab 15.11.
You can use [`rules`](index.md#rules) with `include` to conditionally include other configuration files.
@@ -545,9 +530,6 @@ In this example:
## Use `include:local` with wildcard file paths
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25921) in GitLab 13.11.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/327315) in GitLab 14.2.
-
You can use wildcard paths (`*` and `**`) with `include:local`.
Example:
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 1c9697ac36953bf010f7f87c2c07e25120bbc901..d9c744dc994bcd2b5a110423a2440f2bdd46b371 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -196,8 +196,6 @@ And optionally:
count towards the limit.
- From [GitLab 14.9 to GitLab 15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/28987), you can have up to 100 includes.
The same file can be included multiple times in nested includes, but duplicates are ignored.
- - In GitLab 14.9 and earlier you can have up to 100 includes, but the same file can not
- be included multiple times.
**Related topics**:
@@ -262,8 +260,6 @@ include: '.gitlab-ci-production.yml'
#### `include:project`
-> - Including multiple files from the same project [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26793) in GitLab 13.6. [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/271560) in GitLab 13.8.
-
To include files from another private project on the same GitLab instance,
use `include:project` and `include:file`.
@@ -486,8 +482,6 @@ start. Jobs in the current stage are not stopped and continue to run.
### `workflow`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29654) in GitLab 12.5
-
Use [`workflow`](workflow.md) to control pipeline behavior.
You can use some [predefined CI/CD variables](../variables/predefined_variables.md) in
@@ -682,9 +676,6 @@ and the pipeline is for either:
#### `workflow:rules:variables`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294232) in GitLab 13.11.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/300997) in GitLab 14.1.
-
You can use [`variables`](#variables) in `workflow:rules` to define variables for
specific pipeline conditions.
@@ -1148,9 +1139,6 @@ In this example, `job1` and `job2` run in parallel:
#### `allow_failure:exit_codes`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/273157) in GitLab 13.8.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292024) in GitLab 13.9.
-
Use `allow_failure:exit_codes` to control when a job should be
allowed to fail. The job is `allow_failure: true` for any of the listed exit codes,
and `allow_failure` false for any other exit code.
@@ -1247,9 +1235,6 @@ This example creates an artifact with `.config` and all the files in the `binari
#### `artifacts:exclude`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15122) in GitLab 13.1
-> - Requires GitLab Runner 13.1
-
Use `artifacts:exclude` to prevent files from being added to an artifacts archive.
**Keyword type**: Job keyword. You can use it only as part of a job or in the
@@ -1286,11 +1271,6 @@ subdirectories of `binaries/`.
#### `artifacts:expire_in`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16267) in GitLab 13.0 behind a disabled feature flag, the latest job artifacts are kept regardless of expiry time.
-> - [Made default behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/229936) in GitLab 13.4.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241026) in GitLab 13.8, keeping latest job artifacts can be disabled at the project level.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276583) in GitLab 13.9, keeping latest job artifacts can be disabled instance-wide.
-
Use `expire_in` to specify how long [job artifacts](../jobs/job_artifacts.md) are stored before
they expire and are deleted. The `expire_in` setting does not affect:
@@ -1331,8 +1311,7 @@ job:
If the expiry time is not defined, it defaults to the [instance wide setting](../../administration/settings/continuous_integration.md#default-artifacts-expiration).
- To override the expiration date and protect artifacts from being automatically deleted:
- Select **Keep** on the job page.
- - [In GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/22761), set the value of
- `expire_in` to `never`.
+ - Set the value of `expire_in` to `never`.
- If the expiry time is too short, jobs in later stages of a long pipeline might try to fetch
expired artifacts from earlier jobs. If the artifacts are expired, jobs that try to fetch
them fail with a [`could not retrieve the needed artifacts` error](../jobs/job_artifacts_troubleshooting.md#error-message-this-job-could-not-start-because-it-could-not-retrieve-the-needed-artifacts).
@@ -1341,8 +1320,6 @@ job:
#### `artifacts:expose_as`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15018) in GitLab 12.5.
-
Use the `artifacts:expose_as` keyword to
[expose job artifacts in the merge request UI](../jobs/job_artifacts.md#link-to-job-artifacts-in-the-merge-request-ui).
@@ -1726,8 +1703,6 @@ cache-job:
##### `cache:key:files`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) in GitLab 12.5.
-
Use the `cache:key:files` keyword to generate a new key when one or two specific files
change. `cache:key:files` lets you reuse some caches, and rebuild them less often,
which speeds up subsequent pipeline runs.
@@ -1771,8 +1746,6 @@ use the new cache, instead of rebuilding the dependencies.
##### `cache:key:prefix`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) in GitLab 12.5.
-
Use `cache:key:prefix` to combine a prefix with the SHA computed for [`cache:key:files`](#cachekeyfiles).
**Keyword type**: Job keyword. You can use it only as part of a job or in the
@@ -1884,8 +1857,6 @@ rspec:
#### `cache:when`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18969) in GitLab 13.5 and GitLab Runner v13.5.0.
-
Use `cache:when` to define when to save the cache, based on the status of the job.
Must be used with `cache: paths`, or nothing is cached.
@@ -2047,8 +2018,6 @@ DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5981) in GitLab 14.1.
-
Use the `dast_configuration` keyword to specify a site profile and scanner profile to be used in a
CI/CD configuration. Both profiles must first have been created in the project. The job's stage must
be `dast`.
@@ -2316,8 +2285,6 @@ Every time the review app is deployed, that lifetime is also reset to `1 day`.
#### `environment:kubernetes`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) in GitLab 12.6.
-
Use the `kubernetes` keyword to configure deployments to a
[Kubernetes cluster](../../user/infrastructure/clusters/index.md) that is associated with your project.
@@ -2350,8 +2317,6 @@ environment, using the `production`
#### `environment:deployment_tier`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300741) in GitLab 13.10.
-
Use the `deployment_tier` keyword to specify the tier of the deployment environment.
**Keyword type**: Job keyword. You can use it only as part of a job.
@@ -2461,7 +2426,7 @@ rspec:
**Additional details**:
-- In GitLab 12.0 and later, you can use multiple parents for `extends`.
+- You can use multiple parents for `extends`.
- The `extends` keyword supports up to eleven levels of inheritance, but you should
avoid using more than three levels.
- In the example above, `.tests` is a [hidden job](../jobs/index.md#hide-jobs),
@@ -2769,8 +2734,6 @@ job2:
### `inherit`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207484) in GitLab 12.9.
-
Use `inherit` to [control inheritance of default keywords and variables](../jobs/index.md#control-the-inheritance-of-default-keywords-and-global-variables).
#### `inherit:default`
@@ -2847,7 +2810,6 @@ job2:
### `interruptible`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32022) in GitLab 12.3.
> - Support for `trigger` jobs [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/138508) in GitLab 16.8.
Use `interruptible` to configure the [auto-cancel redundant pipelines](../pipelines/settings.md#auto-cancel-redundant-pipelines)
@@ -2922,11 +2884,6 @@ In this example, a new pipeline causes a running pipeline to be:
### `needs`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063) in GitLab 12.2.
-> - In GitLab 12.3, maximum number of jobs in `needs` array raised from five to 50.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30631) in GitLab 12.8, `needs: []` lets jobs start immediately.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30632) in GitLab 14.2, you can refer to jobs in the same stage as the job you are configuring.
-
Use `needs` to execute jobs out-of-order. Relationships between jobs
that use `needs` can be visualized as a [directed acyclic graph](../directed_acyclic_graph/index.md).
@@ -2937,7 +2894,7 @@ Jobs in multiple stages can run concurrently.
**Possible inputs**:
-- An array of jobs.
+- An array of jobs (maximum of 50 jobs).
- An empty array (`[]`), to set the job to start as soon as the pipeline is created.
**Example of `needs`**:
@@ -2995,13 +2952,7 @@ This example creates four paths of execution:
name, they overwrite each other and only the last one downloaded is saved.
- To have `needs` refer to a subset of parallelized jobs (and not all of the parallelized jobs),
use the [`needs:parallel:matrix`](#needsparallelmatrix) keyword.
-- In [GitLab 14.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/30632) you
- can refer to jobs in the same stage as the job you are configuring. This feature is
- enabled on GitLab.com and ready for production use. On self-managed [GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/30632)
- this feature is available by default.
-- In GitLab 14.0 and earlier, you can only refer to jobs in earlier stages. Stages must be
- explicitly defined for all jobs that use the `needs` keyword, or are referenced
- in a job's `needs` section.
+- You can refer to jobs in the same stage as the job you are configuring.
- If `needs` refers to a job that might not be added to
a pipeline because of `only`, `except`, or `rules`, the pipeline might fail to create. Use the [`needs:optional`](#needsoptional) keyword to resolve a failed pipeline creation.
- If a pipeline has jobs with `needs: []` and jobs in the [`.pre`](#stage-pre) stage, they will
@@ -3010,8 +2961,6 @@ This example creates four paths of execution:
#### `needs:artifacts`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14311) in GitLab 12.6.
-
When a job uses `needs`, it no longer downloads all artifacts from previous stages
by default, because jobs with `needs` can start before earlier stages complete. With
`needs` you can only download artifacts from the jobs listed in the `needs` configuration.
@@ -3065,8 +3014,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14311) in GitLab 12.7.
-
Use `needs:project` to download artifacts from up to five jobs in other pipelines.
The artifacts are downloaded from the latest successful specified job for the specified ref.
To specify multiple jobs, add each as separate array items under the `needs` keyword.
@@ -3107,8 +3054,7 @@ build_job:
In this example, `build_job` downloads the artifacts from the latest successful `build-1` and `build-2` jobs
on the `main` branches in the `group/project-name` and `group/project-name-2` projects.
-In GitLab 13.3 and later, you can use [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
-in `needs:project`, for example:
+You can use [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file) in `needs:project`, for example:
```yaml
build_job:
@@ -3135,9 +3081,7 @@ build_job:
behavior is limited to jobs in the same pipeline. Make sure that the needed job in the other
pipeline completes before the job that needs it tries to download the artifacts.
- You can't download artifacts from jobs that run in [`parallel`](#parallel).
-- Support for [CI/CD variables](../variables/index.md) in `project`, `job`, and `ref` was
- [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202093) in GitLab 13.3.
- [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235761) in GitLab 13.4.
+- Support [CI/CD variables](../variables/index.md) in `project`, `job`, and `ref`.
**Related topics**:
@@ -3146,8 +3090,6 @@ build_job:
#### `needs:pipeline:job`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/255983) in GitLab 13.7.
-
A [child pipeline](../pipelines/downstream_pipelines.md#parent-child-pipelines) can download artifacts from a job in
its parent pipeline or another child pipeline in the same parent-child pipeline hierarchy.
@@ -3200,9 +3142,6 @@ can use that variable in `needs:pipeline` to download artifacts from the parent
#### `needs:optional`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30680) in GitLab 13.10.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/323891) in GitLab 14.0.
-
To need a job that sometimes does not exist in the pipeline, add `optional: true`
to the `needs` configuration. If not defined, `optional: false` is the default.
@@ -3504,8 +3443,6 @@ This example creates 5 jobs that run in parallel, named `test 1/5` to `test 5/5`
#### `parallel:matrix`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15356) in GitLab 13.3.
-> - The job naming style was [improved in GitLab 13.4](https://gitlab.com/gitlab-org/gitlab/-/issues/230452).
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336576) in GitLab 15.9, the maximum number of permutations is increased from 50 to 200.
Use `parallel:matrix` to run a job multiple times in parallel in a single pipeline,
@@ -3592,8 +3529,6 @@ deploystacks: [vultr, processing]
### `release`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19298) in GitLab 13.2.
-
Use `release` to create a [release](../../user/project/releases/index.md).
The release job must have access to the [`release-cli`](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs),
@@ -3758,7 +3693,7 @@ The long description of the release.
**Possible inputs**:
- A string with the long description.
-- The path to a file that contains the description. Introduced in [GitLab 13.7](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/67).
+- The path to a file that contains the description.
- The file location must be relative to the project directory (`$CI_PROJECT_DIR`).
- If the file is a symbolic link, it must be in the `$CI_PROJECT_DIR`.
- The `./path/to/file` and filename can't contain spaces.
@@ -3814,8 +3749,6 @@ released_at: '2021-03-15T08:00:00Z'
#### `release:assets:links`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/271454) in GitLab 13.12.
-
Use `release:assets:links` to include [asset links](../../user/project/releases/release_fields.md#release-assets) in the release.
Requires `release-cli` version v0.4.0 or later.
@@ -3835,8 +3768,6 @@ assets:
### `resource_group`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15536) in GitLab 12.7.
-
Use `resource_group` to create a [resource group](../resource_groups/index.md) that
ensures a job is mutually exclusive across different pipelines for the same project.
@@ -4018,8 +3949,6 @@ using variables.
### `rules`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3.
-
Use `rules` to include or exclude jobs in pipelines.
Rules are evaluated when the pipeline is created, and evaluated *in order*
@@ -4094,9 +4023,7 @@ job:
- If a rule matches and has no `when` defined, the rule uses the `when`
defined for the job, which defaults to `on_success` if not defined.
-- In GitLab 14.5 and earlier, you can define `when` once per rule, or once at the job-level,
- which applies to all rules. You can't mix `when` at the job-level with `when` in rules.
-- In GitLab 14.6 and later, you can [mix `when` at the job-level with `when` in rules](https://gitlab.com/gitlab-org/gitlab/-/issues/219437).
+- You can [mix `when` at the job-level with `when` in rules](https://gitlab.com/gitlab-org/gitlab/-/issues/219437).
`when` configuration in `rules` takes precedence over `when` at the job-level.
- Unlike variables in [`script`](../variables/index.md#use-cicd-variables-in-job-scripts)
sections, variables in rules expressions are always formatted as `$VARIABLE`.
@@ -4128,7 +4055,7 @@ to specify the branch to compare against.
An array including any number of:
-- Paths to files. In GitLab 13.6 and later, [file paths can include variables](../jobs/job_control.md#variables-in-ruleschanges).
+- Paths to files. The [file paths can include variables](../jobs/job_control.md#variables-in-ruleschanges).
A file path array can also be in [`rules:changes:paths`](#ruleschangespaths).
- Wildcard paths for:
- Single directories, for example `path/to/directory/*`.
@@ -4243,7 +4170,6 @@ relative to `refs/heads/branch1` and the pipeline source is a merge request even
#### `rules:exists`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24021) in GitLab 12.4.
> - CI/CD variable support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/283881) in GitLab 15.6.
Use `exists` to run a job when certain files exist in the repository.
@@ -4281,8 +4207,6 @@ job:
#### `rules:allow_failure`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30235) in GitLab 12.8.
-
Use [`allow_failure: true`](#allow_failure) in `rules` to allow a job to fail
without stopping the pipeline.
@@ -4367,9 +4291,6 @@ In this example:
#### `rules:variables`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209864) in GitLab 13.7.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/289803) in GitLab 13.10.
-
Use [`variables`](#variables) in `rules` to define variables for specific conditions.
**Keyword type**: Job-specific. You can use it only as part of a job.
@@ -4471,8 +4392,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) in GitLab 13.4.
-
Use `secrets` to specify [CI/CD secrets](../secrets/index.md) to:
- Retrieve from an external secrets provider.
@@ -4481,8 +4400,6 @@ Use `secrets` to specify [CI/CD secrets](../secrets/index.md) to:
#### `secrets:vault`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/28321) in GitLab 13.4 and GitLab Runner 13.4.
-
Use `secrets:vault` to specify secrets provided by a [HashiCorp Vault](https://www.vaultproject.io/).
**Keyword type**: Job keyword. You can use it only as part of a job.
@@ -4587,8 +4504,6 @@ job:
#### `secrets:file`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250695) in GitLab 14.1 and GitLab Runner 14.1.
-
Use `secrets:file` to configure the secret to be stored as either a
[`file` or `variable` type CI/CD variable](../variables/index.md#use-file-type-cicd-variables)
@@ -4833,8 +4748,6 @@ job4:
#### `stage: .pre`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31441) in GitLab 12.4.
-
Use the `.pre` stage to make a job run at the start of a pipeline. `.pre` is
always the first stage in a pipeline. User-defined stages execute after `.pre`.
You do not have to define `.pre` in [`stages`](#stages).
@@ -4869,8 +4782,6 @@ job2:
#### `stage: .post`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31441) in GitLab 12.4.
-
Use the `.post` stage to make a job run at the end of a pipeline. `.post`
is always the last stage in a pipeline. User-defined stages execute before `.post`.
You do not have to define `.post` in [`stages`](#stages).
@@ -4911,9 +4822,6 @@ job2:
### `tags`
-> - A limit of 50 tags per job [enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/338929) in GitLab 14.3.
-> - A limit of 50 tags per job [enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/339855) in GitLab 14.3.
-
Use `tags` to select a specific runner from the list of all runners that are
available for the project.
@@ -4927,8 +4835,7 @@ be assigned every tag listed in the job.
**Possible inputs**:
- An array of tag names.
-- CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
- in GitLab 14.1 and later.
+- CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `tags`**:
@@ -4943,8 +4850,7 @@ In this example, only runners with *both* the `ruby` and `postgres` tags can run
**Additional details**:
-- In [GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/338479) and later,
- the number of tags must be less than `50`.
+- The number of tags must be less than `50`.
**Related topics**:
@@ -4953,8 +4859,6 @@ In this example, only runners with *both* the `ruby` and `postgres` tags can run
### `timeout`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14887) in GitLab 12.3.
-
Use `timeout` to configure a timeout for a specific job. If the job runs for longer
than the timeout, the job fails.
@@ -4984,7 +4888,6 @@ test:
### `trigger`
-> - Support for `resource_group` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39057) support for `resource_group` in GitLab 13.9.
> - Support for `environment` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369061) in GitLab 16.4.
Use `trigger` to declare that a job is a "trigger job" which starts a
@@ -5026,10 +4929,9 @@ trigger-multi-project-pipeline:
**Additional details**:
-- You [cannot use the API to start `when:manual` trigger jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/284086).
-- In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
- can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and
- earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
+- You can use [`when:manual`](#when) in the same job as `trigger`, but you cannot
+ use the API to start `when:manual` trigger jobs. See [issue 284086](https://gitlab.com/gitlab-org/gitlab/-/issues/284086)
+ for more details.
- You cannot [manually specify CI/CD variables](../jobs/index.md#specifying-variables-when-running-manual-jobs)
before running a manual trigger job.
- [Manual pipeline variables](../variables/index.md#override-a-defined-cicd-variable)
@@ -5268,8 +5170,6 @@ deploy_review_job:
#### `variables:description`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) in GitLab 13.7.
-
Use the `description` keyword to define a description for a pipeline-level (global) variable.
The description displays with [the prefilled variable name when running a pipeline manually](../pipelines/index.md#prefill-variables-in-manual-pipelines).
@@ -5294,8 +5194,6 @@ variables:
#### `variables:value`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) in GitLab 13.7.
-
Use the `value` keyword to define a pipeline-level (global) variable's value. When used with
[`variables: description`](#variablesdescription), the variable value is [prefilled when running a pipeline manually](../pipelines/index.md#prefill-variables-in-manual-pipelines).
@@ -5456,9 +5354,6 @@ In this example, the script:
**Additional details**:
-- In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
- can use `when:manual` in the same job as [`trigger`](#trigger). In GitLab 13.4 and
- earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
- The default behavior of `allow_failure` changes to `true` with `when: manual`.
However, if you use `when: manual` with [`rules`](#rules), `allow_failure` defaults
to `false`.
diff --git a/doc/ci/yaml/workflow.md b/doc/ci/yaml/workflow.md
index 8b75a26777bc96391d5e3673d8e073dc5b2a9e66..c2381626071d00323988745b8609623393277e51 100644
--- a/doc/ci/yaml/workflow.md
+++ b/doc/ci/yaml/workflow.md
@@ -67,8 +67,6 @@ request pipelines.
### Switch between branch pipelines and merge request pipelines
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) in GitLab 13.8.
-
To make the pipeline switch from branch pipelines to merge request pipelines after
a merge request is created, add a `workflow: rules` section to your `.gitlab-ci.yml` file.
@@ -140,8 +138,6 @@ This example assumes that your long-lived branches are [protected](../../user/pr
## `workflow:rules` templates
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217732) in GitLab 13.0.
-
GitLab provides templates that set up `workflow: rules`
for common scenarios. These templates help prevent duplicate pipelines.
diff --git a/doc/ci/yaml/yaml_optimization.md b/doc/ci/yaml/yaml_optimization.md
index 51ebc12eed062ec4d4f254eb815cefe56b23ac14..2e04ce1ffc3b268b252292cb0b3acc54d7f2857c 100644
--- a/doc/ci/yaml/yaml_optimization.md
+++ b/doc/ci/yaml/yaml_optimization.md
@@ -169,7 +169,6 @@ You can see that the hidden jobs are conveniently used as templates, and
### YAML anchors for scripts
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23005) in GitLab 12.5.
> - Support for anchors with the [`stages`](../yaml/index.md#stages) keyword [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/439451) in GitLab 16.9.
You can use [YAML anchors](#anchors) with [script](index.md#script), [`before_script`](index.md#before_script),
@@ -383,9 +382,6 @@ In this example:
## `!reference` tags
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/266173) in GitLab 13.9.
-> - `rules` keyword support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322992) in GitLab 14.3.
-
Use the `!reference` custom YAML tag to select keyword configuration from other job
sections and reuse it in the current section. Unlike [YAML anchors](#anchors), you can
use `!reference` tags to reuse configuration from [included](index.md#include) configuration
@@ -443,7 +439,6 @@ test-vars-2:
### Nest `!reference` tags in `script`, `before_script`, and `after_script`
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74792) in GitLab 14.8.
> - Support for `!reference` with the [`stages`](../yaml/index.md#stages) keyword [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/439451) in GitLab 16.9.
You can nest `!reference` tags up to 10 levels deep in `script`, `before_script`, and `after_script` sections. Use nested tags to define reusable sections when building more complex scripts. For example:
diff --git a/doc/development/cicd/templates.md b/doc/development/cicd/templates.md
index 2cc1994b3e14bbc8d9c66fcc5d825fdcd0664e35..25104f8603c1621624de4f0c5932d451f2eb40a0 100644
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@@ -333,11 +333,10 @@ release milestones. Name the stable version of a template as `<template-name>.gi
for example `Jobs/Deploy.gitlab-ci.yml`.
You can make a new stable template by copying [the latest template](#latest-version)
-available in a major milestone release of GitLab like `13.0`. All breaking changes
-must be announced in a blog post before the official release, for example
-[GitLab.com is moving to 13.0, with narrow breaking changes](https://about.gitlab.com/blog/2020/05/06/gitlab-com-13-0-breaking-changes/)
+available in a major milestone release of GitLab like `15.0`. All breaking changes must be announced
+on the [Deprecations and removals by version](../../update/deprecations.md) page.
-You can change a stable template version in a minor GitLab release like `13.1` if:
+You can change a stable template version in a minor GitLab release like `15.1` if:
- The change is not a [breaking change](#backward-compatibility).
- The change is ported to [the latest template](#latest-version), if one exists.
@@ -357,9 +356,9 @@ If the `latest` template does not exist yet, you can copy [the stable template](
### How to include an older stable template
Users may want to use an older [stable template](#stable-version) that is not bundled
-in the current GitLab package. For example, the stable templates in GitLab 13.0 and
-GitLab 14.0 could be so different that a user wants to continue using the GitLab 13.0
-template even after upgrading to GitLab 14.0.
+in the current GitLab package. For example, the stable templates in GitLab 15.0 and
+GitLab 16.0 could be so different that a user wants to continue using the GitLab 15.0
+template even after upgrading to GitLab 16.0.
You can add a note in the template or in documentation explaining how to use `include:remote`
to include older template versions. If other templates are included with `include: template`,