Add latest changes from gitlab-org/gitlab@master

8 files changed, 185 insertions, 88 deletions

diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index f958cb1db74..d332af418e5 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -45,7 +45,7 @@ can't link to files outside it.
 
 To ensure maximum availability of the cache, do one or more of the following:
 
-- [Tag your runners](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) and use the tag on jobs
+- [Tag your runners](../runners/configure_runners.md#control-jobs-that-a-runner-can-run) and use the tag on jobs
   that share the cache.
 - [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-project-runner-from-being-enabled-for-other-projects).
 - [Use a `key`](../yaml/index.md#cachekey) that fits your workflow. For example,
diff --git a/doc/ci/components/index.md b/doc/ci/components/index.md
index 6f1365561dc..f052fbf98b6 100644
--- a/doc/ci/components/index.md
+++ b/doc/ci/components/index.md
@@ -216,6 +216,17 @@ If you disable [catalog resource setting](#set-a-component-project-as-a-catalog-
 the component project and all versions are removed from the catalog. To publish it again,
 you must re-enable the setting and release a new version.
 
+### Unpublish a component project
+
+To remove a component project from the catalog, turn off the [**CI/CD Catalog resource**](#set-a-component-project-as-a-catalog-resource) toggle.
+in the project settings.
+
+WARNING:
+This action destroys the metadata about the component project and its versions published
+in the catalog. The project and its repository still exist, but are not visible in the catalog.
+
+To publish the component project in the catalog again, you need to [publish a new release](#publish-a-new-release).
+
 ## Best practices
 
 This section describes some best practices for creating high quality component projects.
diff --git a/doc/ci/migration/github_actions.md b/doc/ci/migration/github_actions.md
index edd04743707..ec55f129c1e 100644
--- a/doc/ci/migration/github_actions.md
+++ b/doc/ci/migration/github_actions.md
@@ -466,7 +466,7 @@ Some key details about runners:
 
 - Runners can be [configured](../runners/runners_scope.md) to be shared across an instance,
   a group, or dedicated to a single project.
-- You can use the [`tags` keyword](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run)
+- You can use the [`tags` keyword](../runners/configure_runners.md#control-jobs-that-a-runner-can-run)
   for finer control, and associate runners with specific jobs. For example, you can use a tag for jobs that
   require dedicated, more powerful, or specific hardware.
 - GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html).
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index 12f3901436d..f430b1ac7b9 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -482,7 +482,7 @@ Some key details about runners:
 
 - Runners can be [configured](../runners/runners_scope.md) to be shared across an instance,
   a group, or dedicated to a single project.
-- You can use the [`tags` keyword](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run)
+- You can use the [`tags` keyword](../runners/configure_runners.md#control-jobs-that-a-runner-can-run)
   for finer control, and associate runners with specific jobs. For example, you can use a tag for jobs that
   require dedicated, more powerful, or specific hardware.
 - GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html).
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 6cd38c64e8e..22ff98fe449 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -225,7 +225,7 @@ You can define how long a job can run before it times out.
 
 Jobs that exceed the timeout are marked as failed.
 
-You can override this value [for individual runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
+You can override this value [for individual runners](../runners/configure_runners.md#set-the-maximum-job-timeout).
 
 ## Pipeline badges
 
diff --git a/doc/ci/runners/configure_runners.md b/doc/ci/runners/configure_runners.md
index 3f8d35957ef..eef78b70155 100644
--- a/doc/ci/runners/configure_runners.md
+++ b/doc/ci/runners/configure_runners.md
@@ -11,53 +11,79 @@ If you have installed your own runners, you can configure and secure them in Git
 If you need to configure runners on the machine where you installed GitLab Runner, see
 [the GitLab Runner documentation](https://docs.gitlab.com/runner/configuration/).
 
-## Manually clear the runner cache
+## Set the maximum job timeout
 
-Read [clearing the cache](../caching/index.md#clearing-the-cache).
+You can specify a maximum job timeout for each runner to prevent projects
+with longer job timeouts from using the runner. The maximum job timeout is
+used of it is shorter than the job timeout defined in the project.
 
-## Set maximum job timeout for a runner
+### For a shared runner
 
-For each runner, you can specify a *maximum job timeout*. This timeout,
-if smaller than the [project defined timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run), takes precedence.
+Prerequisites:
 
-This feature can be used to prevent your shared runner from being overwhelmed
-by a project that has jobs with a long timeout (for example, one week).
+- You must be an administrator.
 
-On GitLab.com, you cannot override the job timeout for shared runners and must use the [project defined timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run).
+On GitLab.com, you cannot override the job timeout for shared runners and must use the [project defined timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run) instead.
+
+To set the maximum job timeout:
+
+1. On the left sidebar, at the bottom, select **Admin Area**.
+1. Select **CI/CD > Runners**.
+1. To the right of the runner, you want to edit, select **Edit** (**{pencil}**).
+1. In the **Maximum job timeout** field, enter a value in seconds. The minimum amount is 600 seconds (10 minutes).
+1. Select **Save changes**.
+
+### For a group runner
+
+Prerequisites:
+
+- You must have the Owner role for the group.
+
+To set the maximum job timeout:
+
+1. On the left sidebar, select **Search or go to** and find your group.
+1. Select **Build > Runners**.
+1. To the right of the runner you want to edit, select **Edit** (**{pencil}**).
+1. In the **Maximum job timeout** field, enter a value in seconds. The minimum amount is 600 seconds (10 minutes).
+1. Select **Save changes**.
+
+### For a project runner
+
+Prerequisites:
+
+- You must have the Owner role for the project.
 
 To set the maximum job timeout:
 
 1. On the left sidebar, select **Search or go to** and find your project.
 1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
-1. Select your project runner to edit the settings.
-1. Enter a value under **Maximum job timeout**. Must be 10 minutes or more. If not
-   defined, the [project's job timeout setting](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run)
-   is used.
+1. To the right of the runner you want to edit, select **Edit** (**{pencil}**).
+1. In the **Maximum job timeout** field, enter a value in seconds. The minimum amount is 600 seconds (10 minutes). If not defined, the [job timeout for the project](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run) is used instead.
 1. Select **Save changes**.
 
-How this feature works:
+## How maximum job timeout works
 
 **Example 1 - Runner timeout bigger than project timeout**
 
-1. You set the _maximum job timeout_ for a runner to 24 hours
-1. You set the _CI/CD Timeout_ for a project to **2 hours**
-1. You start a job
-1. The job, if running longer, times out after **2 hours**
+1. You set the _maximum job timeout_ for a runner to 24 hours.
+1. You set the _CI/CD Timeout_ for a project to **2 hours**.
+1. You start a job.
+1. The job, if running longer, times out after **2 hours**.
 
 **Example 2 - Runner timeout not configured**
 
-1. You remove the _maximum job timeout_ configuration from a runner
-1. You set the _CI/CD Timeout_ for a project to **2 hours**
-1. You start a job
-1. The job, if running longer, times out after **2 hours**
+1. You remove the _maximum job timeout_ configuration from a runner.
+1. You set the _CI/CD Timeout_ for a project to **2 hours**.
+1. You start a job.
+1. The job, if running longer, times out after **2 hours**.
 
 **Example 3 - Runner timeout smaller than project timeout**
 
-1. You set the _maximum job timeout_ for a runner to **30 minutes**
-1. You set the _CI/CD Timeout_ for a project to 2 hours
-1. You start a job
-1. The job, if running longer, times out after **30 minutes**
+1. You set the _maximum job timeout_ for a runner to **30 minutes**.
+1. You set the _CI/CD Timeout_ for a project to 2 hours.
+1. You start a job.
+1. The job, if running longer, times out after **30 minutes**.
 
 ## Set `script` and `after_script` timeouts
 
@@ -66,7 +92,7 @@ How this feature works:
 To control the amount of time `script` and `after_script` runs before it terminates, you can set specify a timeout.
 
 For example, you can specify a timeout to terminate a long-running `script` early, so that artifacts and caches can still be uploaded
-before the [job timeout](#set-maximum-job-timeout-for-a-runner) is exceeded.
+before the job timeout is exceeded.
 
 - To set a timeout for `script`, use the job variable `RUNNER_SCRIPT_TIMEOUT`.
 - To set a timeout for `after_script`, and override the default of 5 minutes, use the job variable `RUNNER_AFTER_SCRIPT_TIMEOUT`.
@@ -105,26 +131,11 @@ of shared runners on large GitLab instances. This ensures that you
 control access to your GitLab instances and secure [runner executors](https://docs.gitlab.com/runner/executors/).
 
 If certain executors run a job, the file system, the code the runner executes,
-and the runner authentication token may be exposed. This means that anyone that runs jobs
+and the runner authentication token may be exposed. This means that anyone who runs jobs
 on a _shared runner_ can access another user's code that runs on the runner.
 Users with access to the runner authentication token can use it to create a clone of
 a runner and submit false jobs in a vector attack. For more information, see [Security Considerations](https://docs.gitlab.com/runner/security/).
 
-### Prevent runners from revealing sensitive information
-
-To ensure runners don't reveal sensitive information, you can configure them to only run jobs
-on [protected branches](../../user/project/protected_branches.md), or jobs that have [protected tags](../../user/project/protected_tags.md).
-
-To prevent runners from revealing sensitive information:
-
-1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Settings > CI/CD**.
-1. Expand **Runners**.
-1. Find the runner you want to protect or unprotect. Make sure the runner is enabled.
-1. Select **Edit** (**{pencil}**).
-1. Select the **Protected** checkbox.
-1. Select **Save changes**.
-
 ### Using shared runners in forked projects
 
 When a project is forked, the job settings related to jobs are copied. If you have shared runners
@@ -179,37 +190,129 @@ To reset the runner authentication token:
    - [Create a project runner](runners_scope.md#create-a-project-runner-with-a-runner-authentication-token).
 1. Optional. To verify that the previous runner authentication token has been revoked, use the [Runners API](../../api/runners.md#verify-authentication-for-a-registered-runner).
 
-## Use tags to control which jobs a runner can run
+### Automatically rotate runner authentication tokens
+
+You can specify an interval for runner authentication tokens to rotate.
+This rotation helps ensure the security of the tokens assigned to your runners.
+
+Prerequisites:
+
+- Runners must use [GitLab Runner 15.3 or later](https://docs.gitlab.com/runner/#gitlab-runner-versions).
+- You must be an administrator.
+
+To automatically rotate runner authentication tokens:
+
+1. On the left sidebar, at the bottom, select **Admin Area**.
+1. On the left sidebar, select **Settings > CI/CD**.
+1. Expand **Continuous Integration and Deployment**
+1. Set a **Runners expiration** time for runners, leave empty for no expiration.
+1. Select **Save changes**.
+
+Before the interval expires, runners automatically request a new runner authentication token.
+
+## Prevent runners from revealing sensitive information
+
+To ensure runners don't reveal sensitive information, you can configure them to only run jobs
+on [protected branches](../../user/project/protected_branches.md), or jobs that have [protected tags](../../user/project/protected_tags.md).
+
+### For a shared runner
+
+Prerequisites:
+
+- You must be an administrator.
+
+1. On the left sidebar, at the bottom, select **Admin Area**.
+1. Select **CI/CD > Runners**.
+1. To the right of the runner you want to protect, select **Edit** (**{pencil}**).
+1. Select the **Protected** checkbox.
+1. Select **Save changes**.
 
-You can use [tags](../yaml/index.md#tags) to ensure that runners only run the jobs they are equipped
-to run. For example, you can specify the `rails` tag for runners that have the dependencies to run
+### For a group runner
+
+Prerequisites:
+
+- You must have the Owner role for the group.
+
+1. On the left sidebar, select **Search or go to** and find your group.
+1. Select **Build > Runners**.
+1. To the right of the runner you want to protect, select **Edit** (**{pencil}**).
+1. Select the **Protected** checkbox.
+1. Select **Save changes**.
+
+### For a project runner
+
+Prerequisites:
+
+- You must have the Owner role for the project.
+
+1. On the left sidebar, select **Search or go to** and find your project.
+1. Select **Settings > CI/CD**.
+1. Expand **Runners**.
+1. To the right of the runner you want to protect, select **Edit** (**{pencil}**).
+1. Select the **Protected** checkbox.
+1. Select **Save changes**.
+
+## Control jobs that a runner can run
+
+You can use [tags](../yaml/index.md#tags) to control the jobs a runner can run.
+For example, you can specify the `rails` tag for runners that have the dependencies to run
 Rails test suites.
 
 GitLab CI/CD tags are different to Git tags. GitLab CI/CD tags are associated with runners.
 Git tags are associated with commits.
 
-### Set a runner to run untagged jobs
+### For a shared runner
+
+Prerequisites:
+
+- You must be an administrator.
+
+To set the maximum job timeout:
 
-When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
-[tagged jobs](../yaml/index.md#tags).
-To change this, you must have the Owner role for the project.
+1. On the left sidebar, at the bottom, select **Admin Area**.
+1. Select **CI/CD > Runners**.
+1. To the right of the runner you want to edit, select **Edit** (**{pencil}**).
+1. Set the runner to run tagged or untagged jobs:
+   - To run tagged jobs, in the **Tags** field, enter the job tags separated with a comma. For example, `macos`, `rails`.
+   - To run untagged jobs, select the **Run untagged jobs** checkbox.
+1. Select **Save changes**.
 
-To make a runner pick untagged jobs:
+### For a group runner
+
+Prerequisites:
+
+- You must have the Owner role for the group.
+
+To set the maximum job timeout:
+
+1. On the left sidebar, select **Search or go to** and find your group.
+1. Select **Build > Runners**.
+1. To the right of the runner you want to edit, select **Edit** (**{pencil}**).
+1. Set the runner to run tagged or untagged jobs:
+   - To run tagged jobs, in the **Tags** field, enter the job tags separated with a comma. For example, `macos`, `ruby`.
+   - To run untagged jobs, select the **Run untagged jobs** checkbox.
+1. Select **Save changes**.
+
+### For a project runner
+
+Prerequisites:
+
+- You must have the Owner role for the project.
+
+To set a runner to run tagged jobs:
 
 1. On the left sidebar, select **Search or go to** and find your project.
 1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
-1. Find the runner you want to pick untagged jobs and make sure it's enabled.
-1. Select **Edit** (**{pencil}**).
-1. Select the **Run untagged jobs** checkbox.
+1. To the right of the runner you want to edit, select **Edit** (**{pencil}**).
+1. Set the runner to run tagged or untagged jobs:
+   - To run tagged jobs, in the **Tags** field, enter the job tags separated with a comma. For example, `macos`, `ruby`.
+   - To run untagged jobs, select the **Run untagged jobs** checkbox.
 1. Select **Save changes**.
 
-NOTE:
-The runner tags list cannot be empty when it's not allowed to pick untagged jobs.
-
-Below are some example scenarios of different variations.
+### How the runner uses tags
 
-### Runner runs only tagged jobs
+#### Runner runs only tagged jobs
 
 The following examples illustrate the potential impact of the runner being set
 to run only tagged jobs.
@@ -229,7 +332,7 @@ Example 3:
 1. The runner is configured to run only tagged jobs and has the `docker` tag.
 1. A job that has no tags defined is executed and stuck.
 
-### Runner is allowed to run untagged jobs
+#### Runner is allowed to run untagged jobs
 
 The following examples illustrate the potential impact of the runner being set
 to run tagged and untagged jobs.
@@ -246,7 +349,7 @@ Example 2:
 1. A job that has no tags defined is executed and run.
 1. A second job that has a `docker` tag defined is stuck.
 
-### A runner and a job have multiple tags
+#### A runner and a job have multiple tags
 
 The selection logic that matches the job and runner is based on the list of `tags`
 defined in the job.
@@ -273,7 +376,9 @@ Example 3:
 
 You can use tags to run different jobs on different platforms. For
 example, if you have an OS X runner with tag `osx` and a Windows runner with tag
-`windows`, you can run a job on each platform:
+`windows`, you can run a job on each platform.
+
+Update the `tags` field in the `config.toml`:
 
 ```yaml
 windows job:
@@ -295,7 +400,7 @@ osx job:
 
 > Introduced in [GitLab 14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/35742).
 
-You can use [CI/CD variables](../variables/index.md) with `tags` for dynamic runner selection:
+In the `.gitlab-ci.yml` file, use [CI/CD variables](../variables/index.md) with `tags` for dynamic runner selection:
 
 ```yaml
 variables:
@@ -928,22 +1033,3 @@ No manual intervention should be required, and no running jobs should be affecte
 
 If you need to manually update the runner authentication token, you can run a
 command to [reset the token](https://docs.gitlab.com/runner/commands/#gitlab-runner-reset-token).
-
-### Automatically rotate runner authentication tokens
-
-You can specify an interval for runner authentication tokens to rotate.
-This rotation helps ensure the security of the tokens assigned to your runners.
-
-Prerequisites:
-
-- Ensure your runners are using [GitLab Runner 15.3 or later](https://docs.gitlab.com/runner/#gitlab-runner-versions).
-
-To automatically rotate runner authentication tokens:
-
-1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Settings > CI/CD**.
-1. Expand **Continuous Integration and Deployment**
-1. Set a **Runners expiration** time for runners, leave empty for no expiration.
-1. Select **Save**.
-
-Before the interval expires, runners automatically request a new runner authentication token.
diff --git a/doc/ci/runners/index.md b/doc/ci/runners/index.md
index d6f5d9d0230..1df93ed8896 100644
--- a/doc/ci/runners/index.md
+++ b/doc/ci/runners/index.md
@@ -20,7 +20,7 @@ For more information about the cost factor applied to the machine type based on
 The number of minutes you can use on these runners depends on the [maximum number of units of compute](../pipelines/cicd_minutes.md)
 in your [subscription plan](https://about.gitlab.com/pricing/).
 
-[Untagged](../../ci/runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) jobs automatically run in containers
+[Untagged](../../ci/runners/configure_runners.md#control-jobs-that-a-runner-can-run) jobs automatically run in containers
 on the `small` Linux runners.
 
 The objective is to make 90% of CI/CD jobs start executing in 120 seconds or less. The error rate should be less than 0.5%.
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 6d53d2fd7b1..8d64c82ce46 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -4568,7 +4568,7 @@ In this example, only runners with *both* the `ruby` and `postgres` tags can run
 
 **Related topics**:
 
-- [Use tags to control which jobs a runner can run](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run).
+- [Use tags to control which jobs a runner can run](../runners/configure_runners.md#control-jobs-that-a-runner-can-run).
 - [Select different runner tags for each parallel matrix job](../jobs/job_control.md#select-different-runner-tags-for-each-parallel-matrix-job).
 
 ### `timeout`
@@ -4579,7 +4579,7 @@ Use `timeout` to configure a timeout for a specific job. If the job runs for lon
 than the timeout, the job fails.
 
 The job-level timeout can be longer than the [project-level timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run),
-but can't be longer than the [runner's timeout](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
+but can't be longer than the [runner's timeout](../runners/configure_runners.md#set-the-maximum-job-timeout).
 
 **Keyword type**: Job keyword. You can use it only as part of a job or in the
 [`default` section](#default).