Add latest changes from gitlab-org/gitlab@14-6-stable-eev14.6.0-rc42

2 files changed, 11 insertions, 15 deletions

diff --git a/doc/ci/jobs/ci_job_token.md b/doc/ci/jobs/ci_job_token.md
index b6a3011a3d6..532a0dffbce 100644
--- a/doc/ci/jobs/ci_job_token.md
+++ b/doc/ci/jobs/ci_job_token.md
@@ -4,7 +4,7 @@ group: Pipeline Execution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# GitLab CI/CD job token
+# GitLab CI/CD job token **(FREE)**
 
 When a pipeline job is about to run, GitLab generates a unique token and injects it as the
 [`CI_JOB_TOKEN` predefined variable](../variables/predefined_variables.md).
@@ -61,11 +61,7 @@ tries to steal tokens from other jobs.
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/328553) in GitLab 14.1. [Deployed behind the `:ci_scoped_job_token` feature flag](../../user/feature_flags.md), disabled by default.
 > - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/332272) in GitLab 14.4.
-
-FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature,
-ask an administrator to [disable the `ci_scoped_job_token` flag](../../administration/feature_flags.md).
-On GitLab.com, this feature is available.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/332272) in GitLab 14.6.
 
 You can limit the access scope of a project's CI/CD job token to increase the
 job token's security. A job token might give extra permissions that aren't necessary
@@ -95,7 +91,7 @@ The job token scope is only for controlling access to private projects.
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Expand **Token Access**.
 1. Toggle **Limit CI_JOB_TOKEN access** to enabled.
-1. (Optional) Add existing projects to the token's access scope. The user adding a
+1. Optional. Add existing projects to the token's access scope. The user adding a
    project must have the [maintainer role](../../user/permissions.md) in both projects.
 
 There is [a proposal](https://gitlab.com/groups/gitlab-org/-/epics/3559) to improve
@@ -121,7 +117,7 @@ trigger_pipeline:
 ```
 
 If you use the `CI_PIPELINE_SOURCE` [predefined CI/CD variable](../variables/predefined_variables.md)
-in a pipeline triggered this way, [the value is `pipeline` (not `triggered`)](../triggers/index.md#authentication-tokens).
+in a pipeline triggered this way, [the value is `pipeline` (not `triggered`)](../triggers/index.md#configure-cicd-jobs-to-run-in-triggered-pipelines).
 
 ## Download an artifact from a different pipeline **(PREMIUM)**
 
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index 0f92ae5ca49..596df34b5c2 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -79,7 +79,7 @@ job:
 - In **all other cases**, the job is added to the pipeline, with `when: on_success`.
 
 WARNING:
-If you use a `when:` clause as the final rule (not including `when: never`), two
+If you use a `when` clause as the final rule (not including `when: never`), two
 simultaneous pipelines may start. Both push pipelines and merge request pipelines can
 be triggered by the same event (a push to the source branch for an open merge request).
 See how to [prevent duplicate pipelines](#avoid-duplicate-pipelines)
@@ -153,7 +153,7 @@ To avoid duplicate pipelines, you can:
 - Use [`workflow`](../yaml/index.md#workflow) to specify which types of pipelines
   can run.
 - Rewrite the rules to run the job only in very specific cases,
-  and avoid a final `when:` rule:
+  and avoid a final `when` rule:
 
   ```yaml
   job:
@@ -225,7 +225,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
 | `pipeline`                    | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
 | `push`                        | For pipelines triggered by a `git push` event, including for branches and tags.                                                                                                                                                  |
 | `schedule`                    | For [scheduled pipelines](../pipelines/schedules.md).                                                                                                                                                                            |
-| `trigger`                     | For pipelines created by using a [trigger token](../triggers/index.md#authentication-tokens).                                                                                                                                           |
+| `trigger`                     | For pipelines created by using a [trigger token](../triggers/index.md#configure-cicd-jobs-to-run-in-triggered-pipelines).                                                                                                                                           |
 | `web`                         | For pipelines created by using **Run pipeline** button in the GitLab UI, from the project's **CI/CD > Pipelines** section.                                                                                                       |
 | `webide`                      | For pipelines created by using the [WebIDE](../../user/project/web_ide/index.md).                                                                                                                                                |
 
@@ -335,7 +335,7 @@ to control when to add jobs to pipelines.
 In the following example, `job` runs only for:
 
 - Git tags
-- [Triggers](../triggers/index.md#authentication-tokens)
+- [Triggers](../triggers/index.md#configure-cicd-jobs-to-run-in-triggered-pipelines)
 - [Scheduled pipelines](../pipelines/schedules.md)
 
 ```yaml
@@ -480,8 +480,8 @@ All files are considered to have changed when a scheduled pipeline runs.
 If you use multiple keywords with `only` or `except`, the keywords are evaluated
 as a single conjoined expression. That is:
 
-- `only:` includes the job if **all** of the keys have at least one condition that matches.
-- `except:` excludes the job if **any** of the keys have at least one condition that matches.
+- `only` includes the job if **all** of the keys have at least one condition that matches.
+- `except` excludes the job if **any** of the keys have at least one condition that matches.
 
 With `only`, individual keys are logically joined by an `AND`. A job is added to
 the pipeline if the following is true:
@@ -634,7 +634,7 @@ timed rollout 10%:
   start_in: 30 minutes
 ```
 
-To stop the active timer of a delayed job, click the **{time-out}** (**Unschedule**) button.
+To stop the active timer of a delayed job, select **Unschedule** (**{time-out}**).
 This job can no longer be scheduled to run automatically. You can, however, execute the job manually.
 
 To start a delayed job immediately, select **Play** (**{play}**).