Docs update vale once rule

doc/.vale/gitlab/AfterOnce.yml

----
-# Suggestion: gitlab.AfterOnce
-#
-# 'Once' is frequently misused at GitLab when the user means 'after'.
-#
-# For a list of all options, see https://errata-ai.github.io/vale/styles/
-extends: substitution
-message: 'Usage check: Use "once" for counting ("Run a job once...") and "after" for a sequence ("Run this job after...").'
-link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#language
-level: suggestion
-ignorecase: true
-swap:
-  once: after

doc/.vale/gitlab/SubstitutionSuggestions.yml

@@ -13,3 +13,6 @@ ignorecase: true
 swap:
   since: because
   utilize: use
+  once that: after that
+  once the: after the
+  once you: after you

doc/administration/job_logs.md

@@ -143,7 +143,7 @@ The data flow is the same as described in the [data flow section](#data-flow)
 with one change: _the stored path of the first two phases is different_. This incremental
 log architecture stores chunks of logs in Redis and a persistent store (object storage or database) instead of
 file storage. Redis is used as first-class storage, and it stores up-to 128KB
-of data. Once the full chunk is sent, it is flushed to a persistent store, either object storage (temporary directory) or database.
+of data. After the full chunk is sent, it is flushed to a persistent store, either object storage (temporary directory) or database.
 After a while, the data in Redis and a persistent store will be archived to [object storage](#uploading-logs-to-object-storage).
 
 The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`.
@@ -153,9 +153,9 @@ Here is the detailed data flow:
 1. The runner picks a job from GitLab
 1. The runner sends a piece of log to GitLab
 1. GitLab appends the data to Redis
-1. Once the data in Redis reach 128KB, the data is flushed to a persistent store (object storage or the database).
+1. After the data in Redis reaches 128KB, the data is flushed to a persistent store (object storage or the database).
 1. The above steps are repeated until the job is finished.
-1. Once the job is finished, GitLab schedules a Sidekiq worker to archive the log.
+1. After the job is finished, GitLab schedules a Sidekiq worker to archive the log.
 1. The Sidekiq worker archives the log to object storage and cleans up the log
    in Redis and a persistent store (object storage or the database).
 

doc/ci/README.md

@@ -77,7 +77,7 @@ While building your `.gitlab-ci.yml`, you can use the [CI/CD configuration visua
 
 For a broader overview, see the [CI/CD getting started](quick_start/README.md) guide.
 
-Once you're familiar with how GitLab CI/CD works, see the
+After you're familiar with how GitLab CI/CD works, see the
 [`.gitlab-ci.yml` full reference](yaml/README.md)
 for all the attributes you can set and use.
 

doc/ci/ci_cd_for_external_repos/index.md

@@ -77,7 +77,7 @@ created.
 GitLab CI/CD will create 2 pipelines in this case. One for the
 branch push and one for the external pull request.
 
-Once the Pull Request is closed, no pipelines are created for the external pull
+After the Pull Request is closed, no pipelines are created for the external pull
 request, even if new changes are pushed to the same branch.
 
 ### Additional predefined variables

doc/ci/cloud_deployment/index.md

@@ -239,7 +239,7 @@ pass three JSON input objects, based on existing templates:
 
    - [Template for the _Deploy to EC2_ step on AWS](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html).
 
-1. Once you have completed these three templates based on your requirements, you
+1. After you have completed these three templates based on your requirements, you
    have two ways to pass in these JSON objects:
 
    - They can be three actual files located in your project. You must specify their path relative to

doc/ci/docker/using_docker_build.md

@@ -644,7 +644,7 @@ and [using the OverlayFS storage driver](https://docs.docker.com/engine/userguid
 
 ## Using the GitLab Container Registry
 
-Once you've built a Docker image, you can push it up to the built-in
+After you've built a Docker image, you can push it up to the built-in
 [GitLab Container Registry](../../user/packages/container_registry/index.md#build-and-push-by-using-gitlab-cicd).
 
 ## Troubleshooting

doc/ci/environments/index.md

@@ -442,7 +442,7 @@ The configuration in this section provides a full development workflow where you
 - Tested.
 - Built.
 - Deployed as a Review App.
-- Deployed to a staging server once the merge request is merged.
+- Deployed to a staging server after the merge request is merged.
 - Finally, able to be manually deployed to the production server.
 
 The following combines the previous configuration examples, including:

doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md

@@ -122,7 +122,7 @@ user for your application and add its credentials to GitLab instead of using
 a developer's credentials.
 
 To start a manual deployment in GitLab go to **CI/CD > Pipelines** then click
-on **Run Pipeline**. Once the app is finished deploying it will display the URL
+on **Run Pipeline**. After the app is finished deploying it will display the URL
 of your application in the logs for the `production` job like:
 
 ```shell

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -261,7 +261,7 @@ Please read through the [documentation on CI/CD configuration](../../../ci/yaml/
 ### Build your game with GitLab CI/CD
 
 We need to update our build job to ensure tests get run as well. Add `gulp build-test`
-to the end of the `script` array for the existing `build` job. Once these commands run,
+to the end of the `script` array for the existing `build` job. After these commands run,
 we know we will need to access everything in the `built` folder, given by GitLab CI/CD's `artifacts`.
 We'll also cache `node_modules` to avoid having to do a full re-pull of those dependencies:
 just pack them up in the cache. Here is the full `build` job:

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -632,7 +632,7 @@ After our code passed through the pipeline successfully, we can deploy to our pr
 
 ![pipelines page deploy button](img/pipelines_page_deploy_button.png)
 
-Once the deploy pipeline passed successfully, navigate to **Pipelines > Environments**.
+After the deploy pipeline passed successfully, navigate to **Pipelines > Environments**.
 
 ![environments page](img/environments_page.png)
 

doc/ci/introduction/index.md

@@ -101,7 +101,7 @@ In this file, you can define the scripts you want to run, define include and
 cache dependencies, choose commands you want to run in sequence
 and those you want to run in parallel, define where you want to
 deploy your app, and specify whether you will want to run the scripts automatically
-or trigger any of them manually. Once you're familiar with
+or trigger any of them manually. After you're familiar with
 GitLab CI/CD you can add more advanced steps into the configuration file.
 
 To add scripts to that file, you'll need to organize them in a
@@ -110,7 +110,7 @@ the tests you wish to perform. To visualize the process, imagine
 that all the scripts you add to the configuration file are the
 same as the commands you run on a terminal on your computer.
 
-Once you've added your `.gitlab-ci.yml` configuration file to your
+After you've added your `.gitlab-ci.yml` configuration file to your
 repository, GitLab will detect it and run your scripts with the
 tool called [GitLab Runner](https://docs.gitlab.com/runner/), which
 works similarly to your terminal.
@@ -157,7 +157,7 @@ Consider the following example for how GitLab CI/CD fits in a
 common development workflow.
 
 Assume that you have discussed a code implementation in an issue
-and worked locally on your proposed changes. Once you push your
+and worked locally on your proposed changes. After you push your
 commits to a feature branch in a remote repository in GitLab,
 the CI/CD pipeline set for your project is triggered. By doing
 so, GitLab CI/CD:
@@ -167,7 +167,7 @@ so, GitLab CI/CD:
   - Preview the changes per merge request with Review Apps, as you
     would see in your `localhost`.
 
-Once you're happy with your implementation:
+After you're happy with your implementation:
 
 - Get your code reviewed and approved.
 - Merge the feature branch into the default branch.

doc/ci/pipelines/index.md

@@ -195,7 +195,7 @@ stage has a job with a manual action.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27188) in GitLab 11.11.
 
 Multiple manual actions in a single stage can be started at the same time using the "Play all manual" button.
-Once you click this button, each individual manual action is triggered and refreshed
+After you click this button, each individual manual action is triggered and refreshed
 to an updated status.
 
 This functionality is only available:

doc/ci/quick_start/README.md

@@ -130,7 +130,7 @@ in the future, but it's available for anyone who wants to try it at the above li
 
 ### Push `.gitlab-ci.yml` to GitLab
 
-Once you've created `.gitlab-ci.yml`, you should add it to your Git repository
+After you've created a `.gitlab-ci.yml`, you should add it to your Git repository
 and push it to GitLab.
 
 ```shell

doc/ci/review_apps/index.md

@@ -27,7 +27,7 @@ In the above example:
 
 - A Review App is built every time a commit is pushed to `topic branch`.
 - The reviewer fails two reviews before passing the third review.
-- Once the review has passed, `topic branch` is merged into `master` where it is deployed to staging.
+- After the review has passed, `topic branch` is merged into `master` where it is deployed to staging.
 - After having been approved in staging, the changes that were merged into `master` are deployed in to production.
 
 ## How Review Apps work
@@ -169,7 +169,7 @@ will match `/source\/(.+?\.html).*/` instead of `/source\/(.*)/`,
 and will result in a public path of `index.html`, instead of
 `index.html.haml`.
 
-Once you have the route mapping set up, it will take effect in the following locations:
+After you have the route mapping set up, it will take effect in the following locations:
 
 - In the merge request widget. The:
   - **View app** button will take you to the environment URL set in `.gitlab-ci.yml`.

doc/ci/variables/README.md

@@ -423,7 +423,7 @@ Group-level variables can be added by:
 1. Inputting variable types, keys, and values in the **Variables** section.
    Any variables of [subgroups](../../user/group/subgroups/index.md) are inherited recursively.
 
-Once you set them, they are available for all subsequent pipelines. Any group-level user defined variables can be viewed in projects by:
+After you set them, they are available for all subsequent pipelines. Any group-level user defined variables can be viewed in projects by:
 
 1. Navigating to the project's **Settings > CI/CD** page.
 1. Expanding the **Variables** section.