Change shared runner to instance runner

app/views/shared/runners/_shared_runners_description.html.haml

-- shared_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: help_page_path('ci/runners/runners_scope', anchor: 'shared-runners') }
+- shared_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: help_page_path('ci/runners/runners_scope', anchor: 'instance-runners') }
 
 %h4
   = _('Shared runners')

doc/administration/cicd.md

@@ -105,18 +105,18 @@ to a cron value of `0 */12 * * *` (`00:00` and `12:00` every day).
 You can disable some important but computationally expensive parts of the application
 to relieve stress on the database during ongoing downtime.
 
-### Disable fair scheduling on shared runners
+### Disable fair scheduling on instance runners
 
 When clearing a large backlog of jobs, you can temporarily enable the `ci_queueing_disaster_recovery_disable_fair_scheduling`
 [feature flag](../administration/feature_flags.md). This flag disables fair scheduling
-on shared runners, which reduces system resource usage on the `jobs/request` endpoint.
+on instance runners, which reduces system resource usage on the `jobs/request` endpoint.
 
 When enabled, jobs are processed in the order they were put in the system, instead of
 balanced across many projects.
 
 ### Disable compute quota enforcement
 
-To disable the enforcement of [compute quotas](../ci/pipelines/cicd_minutes.md) on shared runners, you can temporarily
+To disable the enforcement of [compute quotas](../ci/pipelines/cicd_minutes.md) on instance runners, you can temporarily
 enable the `ci_queueing_disaster_recovery_disable_quota` [feature flag](../administration/feature_flags.md).
 This flag reduces system resource usage on the `jobs/request` endpoint.
 

doc/administration/pages/index.md

@@ -60,7 +60,7 @@ Before proceeding with the Pages configuration, you must:
 1. Configure a **wildcard DNS record**.
 1. Optional. Have a **wildcard certificate** for that domain if you decide to
    serve Pages under HTTPS.
-1. Optional but recommended. Enable [Shared runners](../../ci/runners/index.md)
+1. Optional but recommended. Enable [instance runners](../../ci/runners/index.md)
    so that your users don't have to bring their own.
 1. For custom domains, have a **secondary IP**.
 

doc/administration/pages/source.md

@@ -60,7 +60,7 @@ Before proceeding with the Pages configuration, make sure that:
   Pages artifacts.
 - Optional. You have a **wildcard certificate** for the Pages domain if you
   decide to serve Pages (`*.example.io`) under HTTPS.
-- Optional but recommended. You have configured and enabled the [shared runners](../../ci/runners/index.md)
+- Optional but recommended. You have configured and enabled the [instance runners](../../ci/runners/index.md)
   so your users don't have to bring their own.
 
 ### DNS configuration

doc/administration/settings/continuous_integration.md

@@ -31,18 +31,18 @@ From now on, every existing project and newly created ones that don't have a
 If you want to disable it for a specific project, you can do so in
 [its settings](../../topics/autodevops/index.md#enable-or-disable-auto-devops).
 
-## Enable shared runners for new projects
+## Enable instance runners for new projects
 
-You can set all new projects to have the instance's shared runners available by default.
+You can set all new projects to have instance runners available by default.
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
 1. Select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**.
-1. Select the **Enable shared runners for new projects** checkbox.
+1. Select the **Enable instance runners for new projects** checkbox.
 
-Any time a new project is created, the shared runners are available.
+Any time a new project is created, the instance runners are available.
 
-## Shared runners compute quota
+## Instance runners compute quota
 
 As an administrator you can set either a global or namespace-specific
 limit on the number of [compute minutes](../../ci/pipelines/cicd_minutes.md) you can use.
@@ -62,17 +62,15 @@ To enable a project runner for more than one project:
 1. To the left of the project, select **Enable**.
 1. Repeat this process for each additional project.
 
-## Add a message for shared runners
+## Add a message for instance runners
 
-To display details about the instance's shared runners in all projects'
+To display details about the instance runners in all projects'
 runner settings:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
 1. Select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**.
-1. Enter text, including Markdown if you want, in the **Shared runner details** field. For example:
-
-   ![Shared runner details input](img/continuous_integration_shared_runner_details_input_v14_10.png)
+1. Enter text, including Markdown if you want, in the **Instance runner details** field.
 
 To view the rendered details:
 
@@ -80,7 +78,7 @@ To view the rendered details:
 1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 
-![Shared runner details example](img/continuous_integration_shared_runner_details_v14_10.png)
+![Instance runner details example](img/continuous_integration_shared_runner_details_v14_10.png)
 
 ## Maximum artifacts size
 

doc/api/runners.md

@@ -471,7 +471,7 @@ Example response:
 
 ## List project's runners
 
-List all runners available in the project, including from ancestor groups and [any allowed shared runners](../ci/runners/runners_scope.md#enable-shared-runners-for-a-project).
+List all runners available in the project, including from ancestor groups and [any allowed shared runners](../ci/runners/runners_scope.md#enable-instance-runners-for-a-project).
 
 ```plaintext
 GET /projects/:id/runners
@@ -590,7 +590,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
 
 ## List group's runners
 
-List all runners available in the group as well as its ancestor groups, including [any allowed shared runners](../ci/runners/runners_scope.md#enable-shared-runners-for-a-group).
+List all runners available in the group as well as its ancestor groups, including [any allowed shared runners](../ci/runners/runners_scope.md#enable-instance-runners-for-a-group).
 
 ```plaintext
 GET /groups/:id/runners

doc/ci/caching/index.md

@@ -60,7 +60,7 @@ For runners to work with caches efficiently, you must do one of the following:
 - Use a single runner for all your jobs.
 - Use multiple runners that have
   [distributed caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching),
-  where the cache is stored in S3 buckets. Shared runners on GitLab.com behave this way. These runners can be in autoscale mode,
+  where the cache is stored in S3 buckets. Instance runners on GitLab.com behave this way. These runners can be in autoscale mode,
   but they don't have to be. To manage cache objects,
   apply lifecycle rules to delete the cache objects after a period of time.
   Lifecycle rules are available on the object storage server.

doc/ci/cloud_services/index.md

@@ -50,7 +50,7 @@ review for the pipeline, focusing on the additional access. For more information
 - Removes the need to store secrets in your GitLab group or project. Temporary credentials can be retrieved from your cloud provider through OIDC.
 - Provides temporary access to cloud resources with granular GitLab conditionals including a group, project, branch, or tag.
 - Enables you to define separation of duties in the CI/CD job with conditional access to environments. Historically, apps may have been deployed with a designated GitLab Runner that had only access to staging or production environments. This led to Runner sprawl as each machine had dedicated permissions.
-- Allows shared runners to securely access multiple cloud accounts. The access is determined by the JWT token, which is specific to the user running the pipeline.
+- Allows instance runners to securely access multiple cloud accounts. The access is determined by the JWT token, which is specific to the user running the pipeline.
 - Removes the need to create logic to rotate secrets by retrieving temporary credentials by default.
 
 ## How it works

doc/ci/docker/using_docker_build.md

@@ -92,7 +92,7 @@ The Docker image includes all of the `docker` tools and can run
 the job script in context of the image in privileged mode.
 
 You should use Docker-in-Docker with TLS enabled,
-which is supported by [GitLab.com shared runners](../runners/index.md).
+which is supported by [GitLab.com instance runners](../runners/index.md).
 
 You should always pin a specific version of the image, like `docker:24.0.5`.
 If you use a tag like `docker:latest`, you have no control over which version is used.
@@ -638,7 +638,7 @@ When using Docker-in-Docker, Docker downloads all layers of your image every tim
 ## Use the OverlayFS driver
 
 NOTE:
-The shared runners on GitLab.com use the `overlay2` driver by default.
+The instance runners on GitLab.com use the `overlay2` driver by default.
 
 By default, when using `docker:dind`, Docker uses the `vfs` storage driver, which
 copies the file system on every run. You can avoid this disk-intensive operation by using a different driver, for example `overlay2`.

doc/ci/docker/using_docker_images.md

@@ -228,7 +228,7 @@ To define which option should be used, the runner process reads the configuratio
   in GitLab Runner 13.1 and later.
 - [Credentials Store](#use-a-credentials-store) and [Credential Helpers](#use-credential-helpers)
   require binaries to be added to the GitLab Runner `$PATH`, and require access to do so. Therefore,
-  these features are not available on shared runners, or any other runner where the user does not
+  these features are not available on instance runners, or any other runner where the user does not
   have access to the environment where the runner is installed.
 
 ### Use statically-defined credentials

doc/ci/docker/using_kaniko.md

@@ -148,7 +148,7 @@ The [Least Privilege Container Builds with Kaniko on GitLab](https://www.youtube
 video is a walkthrough of the [Kaniko Docker Build](https://gitlab.com/guided-explorations/containers/kaniko-docker-build)
 Guided Exploration project pipeline. It was tested on:
 
-- [GitLab.com shared runners](../runners/index.md)
+- [GitLab.com instance runners](../runners/index.md)
 - [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
 
 The example can be copied to your own group or instance for testing. More details

doc/ci/examples/php.md

@@ -273,7 +273,7 @@ gitlab-runner exec shell test:app
 
 We have set up an [Example PHP Project](https://gitlab.com/gitlab-examples/php) for your convenience
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
-[shared runners](../runners/index.md).
+[instance runners](../runners/index.md).
 
 Want to hack on it? Fork it, commit, and push your changes. Within a few
 moments the changes are picked by a public runner and the job begins.

doc/ci/interactive_web_terminal/index.md

@@ -20,7 +20,7 @@ is deployed, some [security precautions](../../administration/integration/termin
 taken to protect the users.
 
 NOTE:
-[Shared runners on GitLab.com](../runners/index.md) do not
+[Instance runners on GitLab.com](../runners/index.md) do not
 provide an interactive web terminal. Follow
 [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24674) for progress on
 adding support. For groups and projects hosted on GitLab.com, interactive web

doc/ci/migration/circleci.md

@@ -285,7 +285,7 @@ Self-managed runners:
 - Windows
 - macOS
 
-GitLab.com shared runners:
+GitLab.com instance runners:
 
 - Linux
 - [Windows](../runners/saas/windows_saas_runner.md) ([Beta](../../policy/experiment-beta-support.md#beta)).

doc/ci/migration/examples/jenkins-maven.md

@@ -159,7 +159,7 @@ It also increases flexibility for expanding and extending the functionality of t
 Prerequisites:
 
 - A GitLab Runner with the Docker executor that can be used by the project.
-  If you are using GitLab.com, you can use the public shared runners.
+  If you are using GitLab.com, you can use the public instance runners.
 
 This migrated pipeline configuration consists of three global keywords (`stages`, `default`, and `variables`)
 followed by 3 jobs. This configuration makes use of additional GitLab CI/CD features

doc/ci/migration/github_actions.md

@@ -464,7 +464,7 @@ deploy_staging:
 #### Runners
 
 Runners are the services that execute jobs. If you are using GitLab.com, you can use the
-[shared runner fleet](../runners/index.md) to run jobs without provisioning your own self-managed runners.
+[instance runner fleet](../runners/index.md) to run jobs without provisioning your own self-managed runners.
 
 Some key details about runners:
 

doc/ci/migration/jenkins.md

@@ -475,7 +475,7 @@ deploy_staging:
 #### Runners
 
 Like Jenkins agents, GitLab runners are the hosts that run jobs. If you are using GitLab.com,
-you can use the [shared runner fleet](../runners/index.md) to run jobs without provisioning
+you can use the [instance runner fleet](../runners/index.md) to run jobs without provisioning
 your own runners.
 
 To convert a Jenkins agent for use with GitLab CI/CD, uninstall the agent and then

doc/ci/pipelines/cicd_minutes.md

@@ -17,7 +17,7 @@ NOTE:
 The term `CI/CD minutes` is being renamed to `compute minutes`. During this transition, you might see references in the UI and documentation to `CI/CD minutes`, `CI minutes`, `pipeline minutes`, `CI pipeline minutes`, `pipeline minutes quota`, `compute credits`, `compute units`, and `compute minutes`. For more information, see [epic 2150](https://gitlab.com/groups/gitlab-com/-/epics/2150).
 
 Administrators can limit the amount of time that projects can use to run jobs on
-[shared runners](../runners/runners_scope.md#shared-runners) each month. This limit
+[instance runners](../runners/runners_scope.md#instance-runners) each month. This limit
 is tracked with a compute quota.
 
 By default, one minute of execution time by a single job uses
@@ -106,7 +106,7 @@ Prerequisites:
 
 ### View Usage Quota Reports for a group
 
-> - Displaying shared runners duration per project [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355666) in GitLab 15.0.
+> - Displaying instance runners duration per project [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355666) in GitLab 15.0.
 
 Prerequisites:
 
@@ -119,13 +119,13 @@ To view compute usage for your group:
 1. Select **Settings > Usage Quotas**.
 1. Select the **Pipelines** tab.
 
-The projects list shows projects with compute usage or shared runners usage
+The projects list shows projects with compute usage or instance runners usage
 in the current month only. The list includes all projects in the namespace and its
 subgroups, sorted in descending order of compute usage.
 
 ### View Usage Quota reports for a personal namespace
 
-> - Displaying shared runners duration [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345795) in GitLab 15.0.
+> - Displaying instance runners duration [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345795) in GitLab 15.0.
 
 Prerequisites:
 
@@ -138,7 +138,7 @@ You can view the compute usage for a personal namespace:
 1. On the left sidebar, select **Usage Quotas**.
 
 The projects list shows [personal projects](../../user/project/working_with_projects.md#view-personal-projects)
-with compute usage or shared runners usage in the current month only. The list
+with compute usage or instance runners usage in the current month only. The list
 is sorted in descending order of compute usage.
 
 ## Purchase additional compute minutes
@@ -221,7 +221,7 @@ GitLab uses this formula to calculate the compute usage of a job:
 Job duration * Cost factor
 ```
 
-- **Job duration**: The time, in seconds, that a job took to run on a shared runner,
+- **Job duration**: The time, in seconds, that a job took to run on a instance runner,
   not including time spent in the `created` or `pending` statuses.
 - [**Cost factor**](#cost-factor): A number based on project visibility.
 
@@ -241,7 +241,7 @@ can be higher than the end-to-end duration of a pipeline.
 
 ### Cost factor
 
-The cost factors for jobs running on shared runners on GitLab.com are:
+The cost factors for jobs running on instance runners on GitLab.com are:
 
 - `1` for internal, public, and private projects.
 - Exceptions for public projects:
@@ -257,8 +257,8 @@ The cost factors on self-managed instances are:
 
 #### Cost factor for community contributions to GitLab projects
 
-Community contributors can use up to 300,000 minutes on shared runners when contributing to open source projects
-maintained by GitLab. The maximum of 300,000 minutes would only be possible if contributing exclusively to projects [part of the GitLab product](https://handbook.gitlab.com/handbook/engineering/metrics/#projects-that-are-part-of-the-product). The total number of minutes available on shared runners
+Community contributors can use up to 300,000 minutes on instance runners when contributing to open source projects
+maintained by GitLab. The maximum of 300,000 minutes would only be possible if contributing exclusively to projects [part of the GitLab product](https://handbook.gitlab.com/handbook/engineering/metrics/#projects-that-are-part-of-the-product). The total number of minutes available on instance runners
 is reduced by the compute minutes used by pipelines from other projects.
 The 300,000 minutes applies to all SaaS tiers, and the cost factor calculation is:
 
@@ -297,7 +297,7 @@ GitLab SaaS runners have different cost factors, depending on the runner type (L
 ### Monthly reset of compute usage
 
 On the first day of each calendar month, the accumulated compute usage is reset to `0`
-for all namespaces that use shared runners. This means your full quota is available, and
+for all namespaces that use instance runners. This means your full quota is available, and
 calculations start again from `0`.
 
 For example, if you have a monthly quota of `10,000` compute minutes:
@@ -327,7 +327,7 @@ Additional compute minutes are a one-time purchase and do not renew or refresh e
 When the compute quota is used for the current month, GitLab stops
 processing new jobs.
 
-- Any non-running job that should be picked by shared runners is automatically dropped.
+- Any non-running job that should be picked by instance runners is automatically dropped.
 - Any job being retried is automatically dropped.
 - Any running job can be dropped at any point if the overall namespace usage goes over-quota
   by a grace period.
@@ -349,7 +349,7 @@ On GitLab SaaS an in-app banner is displayed and an email notification sent to t
 In some cases, the quota limit is replaced by one of the following labels:
 
 - **Unlimited**: For namespaces with unlimited compute quota.
-- **Not supported**: For namespaces where active shared runners are not enabled.
+- **Not supported**: For namespaces where active instance runners are not enabled.
 
 ## Reduce compute quota usage
 

doc/ci/quick_start/index.md

@@ -30,7 +30,7 @@ To create and run your first pipeline:
 
 1. [Ensure you have runners available](#ensure-you-have-runners-available) to run your jobs.
 
-   If you're using GitLab.com, you can skip this step. GitLab.com provides shared runners for you.
+   If you're using GitLab.com, you can skip this step. GitLab.com provides instance runners for you.
 
 1. [Create a `.gitlab-ci.yml` file](#create-a-gitlab-ciyml-file)
    at the root of your repository. This file is where you define the CI/CD jobs.