Merge branch 'docs-triggers-build-terminology' into 'master'

Modernize vocab in triggers doc

See merge request gitlab-org/gitlab!54195

doc/ci/triggers/README.md

@@ -53,7 +53,7 @@ and it creates a dependent pipeline relation visible on the
 [pipeline graph](../multi_project_pipelines.md). For example:
 
 ```yaml
-build_docs:
+trigger_pipeline:
   stage: deploy
   script:
     - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=master "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
@@ -126,16 +126,14 @@ branches or tags. The `:id` of a project can be found by
 [querying the API](../../api/projects.md) or by visiting the **CI/CD**
 settings page which provides self-explanatory examples.
 
-When a rerun of a pipeline is triggered, the information is exposed in the GitLab
-UI under the **Jobs** page and the jobs are marked as triggered 'by API'.
+When a rerun of a pipeline is triggered, jobs are marked as triggered `by API` in
+**CI/CD > Jobs**.
 
-![Marked rebuilds as on jobs page](img/builds_page.png)
-
-You can see which trigger caused the rebuild by visiting the single job page.
+You can see which trigger caused a job to run by visiting the single job page.
 A part of the trigger's token is exposed in the UI as you can see from the image
 below.
 
-![Marked rebuilds as triggered on a single job page](img/trigger_single_build.png)
+![Marked as triggered on a single job page](img/trigger_single_job.png)
 
 By using cURL you can trigger a pipeline rerun with minimal effort, for example:
 
@@ -146,7 +144,7 @@ curl --request POST \
      "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
 ```
 
-In this case, the project with ID `9` gets rebuilt on `master` branch.
+In this case, the pipeline for the project with ID `9` runs on the `master` branch.
 
 Alternatively, you can pass the `token` and `ref` arguments in the query string:
 
@@ -156,12 +154,12 @@ curl --request POST \
 ```
 
 You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
-you have two projects, A and B, and you want to trigger a rebuild on the `master`
+you have two projects, A and B, and you want to trigger a pipeline on the `master`
 branch of project B whenever a tag on project A is created. This is the job you
 need to add in project A's `.gitlab-ci.yml`:
 
 ```yaml
-build_docs:
+trigger_pipeline:
   stage: deploy
   script:
     - 'curl --request POST --form token=TOKEN --form ref=master "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"'
@@ -170,7 +168,7 @@ build_docs:
 ```
 
 This means that whenever a new tag is pushed on project A, the job runs and the
-`build_docs` job is executed, triggering a rebuild of project B. The
+`trigger_pipeline` job is executed, triggering the pipeline for project B. The
 `stage: deploy` ensures that this job runs only after all jobs with
 `stage: test` complete successfully.
 
@@ -204,7 +202,7 @@ This information is also exposed in the UI. Please note that _values_ are only v
 Using trigger variables can be proven useful for a variety of reasons:
 
 - Identifiable jobs. Since the variable is exposed in the UI you can know
-  why the rebuild was triggered if you pass a variable that explains the
+  why the pipeline was triggered if you pass a variable that explains the
   purpose.
 - Conditional job processing. You can have conditional jobs that run whenever
   a certain variable is present.
@@ -236,7 +234,7 @@ upload_package:
     - if [ -n "${UPLOAD_TO_S3}" ]; then make upload; fi
 ```
 
-You can then trigger a rebuild while you pass the `UPLOAD_TO_S3` variable
+You can then trigger a pipeline while you pass the `UPLOAD_TO_S3` variable
 and the script of the `upload_package` job is run:
 
 ```shell