Add latest changes from gitlab-org/gitlab@16-0-stable-eev16.0.0-rc42

1 files changed, 5 insertions, 3 deletions

diff --git a/doc/architecture/blueprints/runner_scaling/index.md b/doc/architecture/blueprints/runner_scaling/index.md
index 53401d80e34..de1203843aa 100644
--- a/doc/architecture/blueprints/runner_scaling/index.md
+++ b/doc/architecture/blueprints/runner_scaling/index.md
@@ -8,6 +8,8 @@ owning-stage: "~devops::verify"
 participating-stages: []
 ---
 
+<!-- vale gitlab.FutureTense = NO -->
+
 # Next Runner Auto-scaling Architecture
 
 ## Summary
@@ -214,12 +216,12 @@ sequence diagram.
 
 ![GitLab Runner Autoscaling Overview](gitlab-autoscaling-overview.png)
 
-On the diagrams above we see that currently a GitLab Runner Manager runs on a
+On the diagrams above we see that currently a runner manager runs on a
 machine that has access to a cloud provider's API. It is using Docker Machine
 to provision new Virtual Machines with Docker Engine installed and it
 configures the Docker daemon there to allow external authenticated requests. It
 stores credentials to such ephemeral Docker environments on disk. Once a
-machine has been provisioned and made available for GitLab Runner Manager to
+machine has been provisioned and made available for the runner manager to
 run builds, it is using one of the existing executors to run a user-provided
 script. In auto-scaling, this is typically done using the Docker executor.
 
@@ -281,7 +283,7 @@ coupled with the VM lifecycle and job routing logic. Creating idle capacity
 happens as a side-effect of calling [`Acquire`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/267f40d871cd260dd063f7fbd36a921fedc62241/executors/docker/machine/provider.go#L449) on the `machineProvider` while binding a job to a VM.
 
 There is also no current abstraction for in-VM job execution. VM-specific
-commands are generated by the Runner Manager using the [`GenerateShellScript`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/267f40d871cd260dd063f7fbd36a921fedc62241/common/build.go#L336)
+commands are generated by the runner manager using the [`GenerateShellScript`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/267f40d871cd260dd063f7fbd36a921fedc62241/common/build.go#L336)
 function and [injected](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/267f40d871cd260dd063f7fbd36a921fedc62241/common/build.go#L373)
 into the VM as the manager drives the job execution stages.