Remove outdated mentions

Author: Filip Aleksic

config.toml.example

@@ -2,31 +2,31 @@ concurrent = 4
 
 [[runners]]
   name = "shell"
-  url = "https://CI/"
+  url = "https://gitlab.com/"
   token = "TOKEN"
   limit = 2
   executor = "shell"
   builds_dir = ""
   shell = "bash"
 
 [[runners]]
-  name = "ruby-2.7-docker"
-  url = "https://CI/"
+  name = "ruby-3.1-docker"
+  url = "https://gitlab.com/"
   token = "TOKEN"
   limit = 0
   executor = "docker"
   builds_dir = ""
   [runners.docker]
     host = ""
-    image = "ruby:2.7"
+    image = "ruby:3.1"
     privileged = false
     disable_cache = false
     cache_dir = ""
 
 
 [[runners]]
   name = "production-server"
-  url = "https://CI/"
+  url = "https://gitlab.com/"
   token = "TOKEN"
   limit = 0
   executor = "ssh"

docs/commands/_index.md

@@ -157,7 +157,7 @@ USAGE:
    gitlab-runner [global options] command [command options] [arguments...]
 
 VERSION:
-   16.5.0 (853330f9)
+   17.10.1 (ef334dcc)
 
 AUTHOR:
    GitLab Inc. <[email protected]>
@@ -176,12 +176,15 @@ COMMANDS:
    run-single            start single runner
    unregister            unregister specific runner
    verify                verify all registered runners
+   wrapper               start multi runner service wrapped with gRPC manager server
+   fleeting              manage fleeting plugins
    artifacts-downloader  download and extract build artifacts (internal)
    artifacts-uploader    create and upload build artifacts (internal)
    cache-archiver        create and upload cache artifacts (internal)
    cache-extractor       download and extract cache artifacts (internal)
    cache-init            changed permissions for cache paths (internal)
    health-check          check health for a specific address
+   proxy-exec            execute internal commands (internal)
    read-logs             reads job logs from a file, used by kubernetes executor (internal)
    help, h               Shows a list of commands or help for one command
 

docs/configuration/advanced-configuration.md

@@ -267,8 +267,8 @@ Example:
 
 ```toml
 [[runners]]
-  name = "ruby-3.3-docker"
-  url = "https://CI/"
+  name = "example-runner"
+  url = "http://gitlab.example.com/"
   token = "TOKEN"
   limit = 0
   executor = "docker"
@@ -353,8 +353,8 @@ CI/CD jobs run locally on the host machine when configured to use the shell exec
 | ----- | ----------- |
 | `bash`        | Generate Bash (Bourne-shell) script. All commands executed in Bash context. Default for all Unix systems. |
 | `sh`          | Generate Sh (Bourne-shell) script. All commands executed in Sh context. The fallback for `bash` for all Unix systems. |
-| `powershell`  | Generate PowerShell script. All commands are executed in PowerShell Desktop context. In GitLab Runner 12.0-13.12, this is the default for Windows. |
-| `pwsh`        | Generate PowerShell script. All commands are executed in PowerShell Core context. In GitLab Runner 14.0 and later, this is the default for Windows. |
+| `powershell`  | Generate PowerShell script. All commands are executed in PowerShell Desktop context. |
+| `pwsh`        | Generate PowerShell script. All commands are executed in PowerShell Core context. This is the default shell for Windows. |
 
 When the `shell` option is set to `bash` or `sh`, Bash's [ANSI-C quoting](https://www.gnu.org/software/bash/manual/html_node/ANSI_002dC-Quoting.html) is used
 to shell escape job scripts.
@@ -658,12 +658,6 @@ The `start_type` parameter determines the graphical front end used when starting
 
 ## Overriding the base VM image
 
-{{< history >}}
-
-- Introduced in GitLab Runner 14.2.
-
-{{< /history >}}
-
 For both the Parallels and VirtualBox executors, you can override the base VM name specified by `base_name`.
 To do this, use the [image](https://docs.gitlab.com/ci/yaml/#image) parameter in the `.gitlab-ci.yml` file.
 
@@ -1404,12 +1398,6 @@ If you use ADC, be sure that the service account that you use has the `iam.servi
 
 ### The `[runners.cache.azure]` section
 
-{{< history >}}
-
-- Introduced in GitLab Runner 13.4.0.
-
-{{< /history >}}
-
 The following parameters define native support for Azure Blob Storage. To learn more, view the
 [Azure Blob Storage documentation](https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction).
 While S3 and GCS use the word `bucket` for a collection of objects, Azure uses the word
@@ -1500,12 +1488,6 @@ For more details, see [issue 38330](https://gitlab.com/gitlab-org/gitlab-runner/
 
 ## The `[runners.kubernetes]` section
 
-{{< history >}}
-
-- Introduced in GitLab Runner v1.6.0.
-
-{{< /history >}}
-
 The following table lists configuration parameters available for the Kubernetes executor.
 For more parameters, see the [documentation for the Kubernetes executor](../executors/kubernetes/_index.md).
 
@@ -1661,7 +1643,7 @@ One of the main reasons for providing these images is that GitLab Runner is usin
 API that is expected to be the same in both binaries.
 
 By default, GitLab Runner references a `registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:XYZ` image, where `XYZ` is based
-on the GitLab Runner architecture and Git revision. In GitLab Runner 11.3 and later, you can define the
+on the GitLab Runner architecture and Git revision. You can define the
 image version by using one of the
 [version variables](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/common/version.go#L48-49):
 
@@ -1679,8 +1661,7 @@ which is based on its compilation data. After updating GitLab Runner to a new ve
 Runner tries to download the proper image. The image should be uploaded to the registry
 before upgrading GitLab Runner, otherwise the jobs start failing with a "No such image" error.
 
-In GitLab Runner 13.2 and later, the helper image is tagged by
-`$CI_RUNNER_VERSION` in addition to `$CI_RUNNER_REVISION`. Both tags are
+The helper image is tagged by `$CI_RUNNER_VERSION` in addition to `$CI_RUNNER_REVISION`. Both tags are
 valid and point to the same image.
 
 ```toml

docs/configuration/autoscale.md

@@ -12,12 +12,6 @@ title: Docker Machine Executor autoscale configuration
 
 {{< /details >}}
 
-{{< history >}}
-
-- The autoscale feature was introduced in GitLab Runner 1.1.0.
-
-{{< /history >}}
-
 {{< alert type="note" >}}
 
 The Docker Machine executor was deprecated in GitLab 17.5 and is scheduled for removal in GitLab 20.0 (May 2027).
@@ -222,12 +216,7 @@ We say that each machine that does not run a job is in idle state. When
 GitLab Runner is in autoscale mode, it monitors all machines and ensures that
 there is always an `IdleCount` of machines in idle state.
 
-{{< alert type="note" >}}
-
-In GitLab Runner 14.5 we've added the `IdleScaleFactor` and `IdleCountMin` settings which change this
-behavior a little. Refer to [the dedicated section](#the-idlescalefactor-strategy) for more details.
-
-{{< /alert >}}
+For more information, see [the dedicated section](#the-idlescalefactor-strategy).
 
 If there is an insufficient number of idle machines, GitLab Runner
 starts provisioning new machines, subject to the `MaxGrowthRate` limit.
@@ -371,12 +360,6 @@ In the worst case scenario, you can't have 10 idle machines, but only 5, because
 
 ## The `IdleScaleFactor` strategy
 
-{{< history >}}
-
-- Introduced as experimental feature in [GitLab Runner 14.6](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3179).
-
-{{< /history >}}
-
 The `IdleCount` parameter defines a static number of idle machines that runner should sustain.
 The value you assign depends on your use case.
 

docs/configuration/feature-flags.md

@@ -125,7 +125,7 @@ in the [Runner configuration](advanced-configuration.md):
 ```toml
 [[runners]]
   name = "example-runner"
-  url = "https://gitlab.example.com/"
+  url = "https://gitlab.com/"
   token = "TOKEN"
   limit = 0
   executor = "docker"
@@ -145,7 +145,7 @@ they don't deal with how the job is executed.
 ```toml
 [[runners]]
   name = "example-runner"
-  url = "https://gitlab.example.com/"
+  url = "https://gitlab.com/"
   token = "TOKEN"
   executor = "docker"
   [runners.feature_flags]

docs/executors/custom.md

@@ -12,12 +12,6 @@ title: The Custom executor
 
 {{< /details >}}
 
-{{< history >}}
-
-- [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2885) in GitLab Runner 12.1
-
-{{< /history >}}
-
 GitLab Runner provides the Custom executor for environments that it
 doesn't support natively. For example, `LXD` or `Libvirt`.
 
@@ -117,12 +111,6 @@ The stages run in the following sequence:
 
 ### Services
 
-{{< history >}}
-
-- [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4358) in GitLab Runner 13.6
-
-{{< /history >}}
-
 [Services](https://docs.gitlab.com/ci/services/) are exposed as a JSON array
 as `CUSTOM_ENV_CI_JOB_SERVICES`.
 
@@ -305,12 +293,6 @@ order:
 1. `upload_artifacts_on_success` OR `upload_artifacts_on_failure`
 1. `cleanup_file_variables`
 
-{{< alert type="note" >}}
-
-In GitLab Runner 14.0 and later, `build_script` is replaced with `step_script`. For more information, see [issue 26426](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426).
-
-{{< /alert >}}
-
 For each stage mentioned above, the `run_exec` executable is
 executed with:
 
@@ -374,7 +356,6 @@ what the main goal of that script is.
 | `restore_cache` | Extract the cache if any are defined. This expects the `gitlab-runner` binary is available in `$PATH`. |
 | `download_artifacts` | Download artifacts, if any are defined. This expects `gitlab-runner` binary is available in `$PATH`. |
 | `step_*` | Generated by GitLab. A set of scripts to execute. It may never be sent to the custom executor. It may have multiple steps, like `step_release` and `step_accessibility`. This can be a feature from the `.gitlab-ci.yml` file. |
-| `build_script` | A combination of [`before_script`](https://docs.gitlab.com/ci/yaml/#before_script-and-after_script) and [`script`](https://docs.gitlab.com/ci/yaml/#script). In GitLab Runner 14.0 and later, `build_script` is replaced with `step_script`. For more information, see [this issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426). |
 | `after_script` | [`after_script`](https://docs.gitlab.com/ci/yaml/#before_script-and-after_script) defined from the job. This script is always called even if any of the previous steps failed. |
 | `archive_cache` | Creates an archive of all the cache, if any are defined. Only executed when `build_script` was successful. |
 | `archive_cache_on_failure` | Creates an archive of all the cache, if any are defined. Only executed when `build_script` fails. |

docs/executors/custom_examples/libvirt.md

@@ -16,10 +16,6 @@ Using [libvirt](https://libvirt.org/), the Custom executor driver will
 create a new disk and VM for every job it executes, after which the disk
 and VM will be deleted.
 
-This example is inspired by a Community Contribution
-[!464](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/464)
-to add libvirt as a GitLab Runner executor.
-
 This document does not try to explain how to set up libvirt, since it's
 out of scope. However, this driver was tested using
 [GCP Nested Virtualization](https://cloud.google.com/compute/docs/instances/nested-virtualization/overview),
@@ -39,11 +35,11 @@ every build. In the following example,
 create a disk VM image.
 
 ```shell
-virt-builder debian-11 \
+virt-builder debian-12 \
     --size 8G \
     --output /var/lib/libvirt/images/gitlab-runner-base.qcow2 \
     --format qcow2 \
-    --hostname gitlab-runner-bullseye \
+    --hostname gitlab-runner-bookworm \
     --network \
     --install curl \
     --run-command 'curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash' \

docs/executors/custom_examples/lxd.md

@@ -18,7 +18,7 @@ up afterwards.
 This example uses a bash script for each stage. You can specify your
 own image, which is exposed as
 [CI_JOB_IMAGE](https://docs.gitlab.com/ci/variables/predefined_variables/).
-This example uses the `ubuntu:18.04` image for simplicity. If you
+This example uses the `ubuntu:22.04` image for simplicity. If you
 want to support multiple images, you would have to modify the executor.
 
 These scripts have the following prerequisites:
@@ -31,7 +31,7 @@ These scripts have the following prerequisites:
 ```toml
 [[runners]]
   name = "lxd-driver"
-  url = "https://www.gitlab.com"
+  url = "https://gitlab.example.com"
   token = "xxxxxxxxxxx"
   executor = "custom"
   builds_dir = "/builds"
@@ -93,7 +93,7 @@ start_container () {
     # user to specify the image. The rest of the script assumes that
     # you are running on an ubuntu image so modifications might be
     # required.
-    lxc launch ubuntu:18.04 "$CONTAINER_ID"
+    lxc launch ubuntu:22.04 "$CONTAINER_ID"
 
     # Wait for container to start, we are using systemd to check this,
     # for the sake of brevity.

docs/executors/docker.md

@@ -564,12 +564,6 @@ By default, the Docker executor stores builds and caches in the following direct
 
 ## Clear the Docker cache
 
-{{< history >}}
-
-- Introduced in GitLab Runner 13.9, [all created runner resources cleaned up](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2310).
-
-{{< /history >}}
-
 Use [`clear-docker-cache`](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/packaging/root/usr/share/gitlab-runner/clear-docker-cache) to remove unused containers and volumes created by the runner.
 
 For a list of options, run the script with the `help` option:
@@ -1050,12 +1044,6 @@ Set the `never` policy in the `config.toml`:
 
 ### Set multiple pull policies
 
-{{< history >}}
-
-- [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26558) in GitLab Runner 13.8.
-
-{{< /history >}}
-
 You can list multiple pull policies to execute if a pull fails. The runner processes pull policies
 in the order listed until a pull attempt is successful or the list is exhausted. For example, if a
 runner uses the `always` pull policy and the registry is not available, you can add the `if-not-present`
@@ -1110,7 +1098,7 @@ For example, to allow only the `always` and `if-not-present` pull policies, add
 |-----------------------------|------------------------------|
 | `Pulling docker image registry.tld/my/image:latest ... ERROR: Build failed: Error: image registry.tld/my/image:latest not found`  |  The runner cannot find the image. Displays when the `always` pull policy is set  |
 | `Pulling docker image local_image:latest ... ERROR: Build failed: Error: image local_image:latest not found`   | The image was built locally and doesn't exist in any public or default Docker registry. Displays when the `always` pull policy is set.   |
-| `Pulling docker image registry.tld/my/image:latest ... WARNING: Cannot pull the latest version of image registry.tld/my/image:latest : Error: image registry.tld/my/image:latest not found WARNING: Locally found image will be used instead.` | The runner has used a local image instead of pulling an image. Displays when the `always` pull policy is set in only [GitLab Runner 1.8 and earlier](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1905).  |
+| `Pulling docker image registry.tld/my/image:latest ... WARNING: Cannot pull the latest version of image registry.tld/my/image:latest : Error: image registry.tld/my/image:latest not found WARNING: Locally found image will be used instead.` | The runner has used a local image instead of pulling an image. |
 | `Pulling docker image local_image:latest ... ERROR: Build failed: Error: image local_image:latest not found` | The image cannot be found locally. Displays when the `never` pull policy is set. |
 | `WARNING: Failed to pull image with policy "always": Error response from daemon: received unexpected HTTP status: 502 Bad Gateway (docker.go:143:0s) Attempt #2: Trying "if-not-present" pull policy Using locally found image version due to "if-not-present" pull policy`| The runner failed to pull an image and attempts to pull an image by using the next listed pull policy. Displays when multiple pull policies are set. |
 
@@ -1132,24 +1120,12 @@ but only takes effect if specifically the Docker pull fails initially.
 
 ## Use Windows containers
 
-{{< history >}}
-
-- [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/535) in GitLab Runner 11.11.
-
-{{< /history >}}
-
 To use Windows containers with the Docker executor, note the following
 information about limitations, supported Windows versions, and
 configuring a Windows Docker executor.
 
 ### Nanoserver support
 
-{{< history >}}
-
-- [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2492) in GitLab Runner 13.6.
-
-{{< /history >}}
-
 With the support for PowerShell Core introduced in the Windows helper image, it is now possible to leverage
 the `nanoserver` variants for the helper image.
 
@@ -1256,8 +1232,7 @@ section.
 
 ### Services
 
-In [GitLab Runner 12.9 and later](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1042),
-you can use [services](https://docs.gitlab.com/ci/services/) by
+You can use [services](https://docs.gitlab.com/ci/services/) by
 enabling [a network for each job](#create-a-network-for-each-job).
 
 ## Native Step Runner Integration