Merge branch 'docs-yaml-notes' into 'master'

Adjust usage of NOTE: in CI docs (1/2)

See merge request gitlab-org/gitlab!45173

doc/ci/ci_cd_for_external_repos/github_integration.md

@@ -21,7 +21,6 @@ cannot be used to authenticate with GitHub as an external CI/CD repository.
 
 ## Connect with Personal Access Token
 
-NOTE: **Note:**
 Personal access tokens can only be used to connect GitHub.com
 repositories to GitLab, and the GitHub user must have the [owner role](https://docs.github.com/en/github/getting-started-with-github/access-permissions-on-github).
 
@@ -53,7 +52,6 @@ GitLab will:
 
 ## Connect manually
 
-NOTE: **Note:**
 To use **GitHub Enterprise** with **GitLab.com**, use this method.
 
 To manually enable GitLab CI/CD for your repository:

doc/ci/ci_cd_for_external_repos/index.md

@@ -74,7 +74,6 @@ If changes are pushed to the branch referenced by the Pull Request and the
 Pull Request is still open, a pipeline for the external pull request is
 created.
 
-NOTE: **Note:**
 GitLab CI/CD will create 2 pipelines in this case. One for the
 branch push and one for the external pull request.
 

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -143,7 +143,6 @@ Now, let's clone our repository on the server just to make sure the `deployer` u
 git clone git@gitlab.example.com:<USERNAME>/laravel-sample.git
 ```
 
-NOTE: **Note:**
 Answer **yes** if asked `Are you sure you want to continue connecting (yes/no)?`.
 It adds GitLab.com to the known hosts.
 
@@ -167,7 +166,6 @@ server {
 }
 ```
 
-NOTE: **Note:**
 You may replace the app's name in `/var/www/app/current/public` with the folder name of your application.
 
 ## Setting up Envoy
@@ -441,7 +439,9 @@ On your GitLab project repository navigate to the **Registry** tab.
 
 You may need to enable the Container Registry for your project to see this tab. You'll find it under your project's **Settings > General > Visibility, project features, permissions**.
 
-To start using Container Registry on our machine, we first need to sign in to the GitLab registry using our GitLab username and password:
+To start using Container Registry on our machine, we first need to sign in to the GitLab registry using our GitLab username and password.
+Make sure you have [Docker](https://docs.docker.com/engine/installation/) installed on our machine,
+then run the following commands:
 
 ```shell
 docker login registry.gitlab.com
@@ -455,14 +455,10 @@ docker build -t registry.gitlab.com/<USERNAME>/laravel-sample .
 docker push registry.gitlab.com/<USERNAME>/laravel-sample
 ```
 
-NOTE: **Note:**
-To run the above commands, we first need to have [Docker](https://docs.docker.com/engine/installation/) installed on our machine.
-
 Congratulations! You just pushed the first Docker image to the GitLab Registry, and if you refresh the page you should be able to see it:
 
 ![container registry page with image](img/container_registry_page_with_image.jpg)
 
-NOTE: **Note:**
 You can also [use GitLab CI/CD](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/#use-with-gitlab-ci) to build and push your Docker images, rather than doing that on your machine.
 
 We'll use this image further down in the `.gitlab-ci.yml` configuration file to handle the process of testing and deploying our app.
@@ -542,7 +538,6 @@ services:
 ...
 ```
 
-NOTE: **Note:**
 If you wish to test your app with different PHP versions and [database management systems](../../services/README.md), you can define different `image` and `services` keywords for each test job.
 
 #### Variables

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -117,7 +117,6 @@ Generated hello_gitlab_ci app
 The database for HelloGitlabCi.Repo has been created
 ```
 
-NOTE: **Note:**
 Phoenix assumes that our PostgreSQL database will have a `postgres` user account with the correct
 permissions and a password of `postgres`. If it's not your case, check
 [Ecto's instructions](https://hexdocs.pm/ecto/Ecto.html#module-repositories).
@@ -205,7 +204,6 @@ when running our Phoenix in our `localhost`.
   Without `.gitkeep`, Git will not upload this empty directory and we'll got an error when running our
   test on GitLab.
 
-  NOTE: **Note:**
   If we add a folder via the GitLab UI, GitLab itself will add the `.gitkeep` to that new dir.
 
 Now, let's run a local test and see if everything we did didn't break anything.

doc/ci/merge_request_pipelines/index.md

@@ -24,7 +24,6 @@ can run a pipeline for merge requests.
 
 ![Merge request page](img/merge_request.png)
 
-NOTE: **Note:**
 If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
 pipelines for merge requests take precedence over the other regular pipelines.
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md

@@ -37,7 +37,6 @@ run.
 
 To add a merge request to a merge train, you need [permissions](../../../../user/permissions.md) to push to the target branch.
 
-NOTE: **Note:**
 Each merge train can run a maximum of **twenty** pipelines in parallel.
 If more than twenty merge requests are added to the merge train, the merge requests
 will be queued until a slot in the merge train is free. There is no limit to the

doc/ci/pipelines/index.md

@@ -10,7 +10,7 @@ type: reference
 
 > Introduced in GitLab 8.8.
 
-NOTE: **Tip:**
+TIP: **Tip:**
 Watch the
 ["Mastering continuous software development"](https://about.gitlab.com/webcast/mastering-ci-cd/)
 webcast to see a comprehensive demo of a GitLab CI/CD pipeline.
@@ -495,7 +495,6 @@ and their statuses.
 Pipeline graphs can be displayed in two different ways, depending on the page you
 access the graph from.
 
-NOTE: **Note:**
 GitLab capitalizes the stages' names in the pipeline graphs.
 
 ### Regular pipeline graphs

doc/ci/pipelines/job_artifacts.md

@@ -61,12 +61,10 @@ The `artifacts:reports` keyword is used for collecting test reports, code qualit
 reports, and security reports from jobs. It also exposes these reports in GitLab's
 UI (merge requests, pipeline views, and security dashboards).
 
-NOTE: **Note:**
 The test reports are collected regardless of the job results (success or failure).
 You can use [`artifacts:expire_in`](../yaml/README.md#artifactsexpire_in) to set up an expiration
 date for their artifacts.
 
-NOTE: **Note:**
 If you also want the ability to browse the report output files, include the
 [`artifacts:paths`](../yaml/README.md#artifactspaths) keyword.
 
@@ -96,7 +94,6 @@ rspec:
 
 The collected Unit test reports upload to GitLab as an artifact and display in merge requests.
 
-NOTE: **Note:**
 If the JUnit tool you use exports to multiple XML files, specify
 multiple test report paths within a single job to
 concatenate them into a single file. Use a filename pattern (`junit: rspec-*.xml`),

doc/ci/pipelines/schedules.md

@@ -11,9 +11,6 @@ type: reference, howto
 > - Introduced in GitLab 9.1 as [Trigger Schedule](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10533).
 > - [Renamed to Pipeline Schedule](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10853) in GitLab 9.2.
 
-NOTE: **Note:**
-Cron notation is parsed by [Fugit](https://github.com/floraison/fugit).
-
 Pipelines are normally run based on certain conditions being met. For example, when a branch is pushed to repository.
 
 Pipeline schedules can be used to also run [pipelines](index.md) at specific intervals. For example:
@@ -24,6 +21,8 @@ Pipeline schedules can be used to also run [pipelines](index.md) at specific int
 In addition to using the GitLab UI, pipeline schedules can be maintained using the
 [Pipeline schedules API](../../api/pipeline_schedules.md).
 
+Schedule timing is configured with cron notation, parsed by [Fugit](https://github.com/floraison/fugit).
+
 ## Prerequisites
 
 In order for a scheduled pipeline to be created successfully:

doc/ci/pipelines/settings.md

@@ -36,13 +36,11 @@ in `.gitlab-ci.yml`.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28919) in GitLab 12.0.
 
-NOTE: **Note:**
-As of GitLab 12.0, newly created projects automatically have a default
-`git depth` value of `50`.
-
 It is possible to limit the number of changes that GitLab CI/CD fetches when cloning
-a repository. Setting a limit to `git depth` can speed up Pipelines execution. Maximum
-allowed value is `1000`.
+a repository. Setting a limit to `git depth` can speed up Pipelines execution.
+
+In GitLab 12.0 and later, newly created projects automatically have a default
+`git depth` value of `50`. The maximum allowed value is `1000`.
 
 To disable shallow clone and make GitLab CI/CD fetch all branches and tags each time,
 keep the value empty or set to `0`.
@@ -180,8 +178,7 @@ This also determines the visibility of these related features:
 - Job artifacts
 - The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**
 
-NOTE: **Note:**
-Currently, job logs and artifacts are [not yet visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
+Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
 
 If **Public pipelines** is enabled (default):
 

doc/ci/variables/README.md

@@ -243,7 +243,7 @@ Some variables are listed in the UI so you can choose them more quickly.
 | `AWS_DEFAULT_REGION`    | Any                                                | 12.10         |
 | `AWS_SECRET_ACCESS_KEY` | Any                                                | 12.10         |
 
-NOTE: **Note:**
+CAUTION: **Caution:**
 When you store credentials, there are security implications. If you are using AWS keys,
 for example, follow their [best practices](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html).
 
@@ -371,9 +371,6 @@ export GITLAB_USER_ID="42"
 
 ## `.gitlab-ci.yml` defined variables
 
-NOTE: **Note:**
-This feature requires GitLab Runner 0.5.0 or higher and GitLab 7.14 or higher.
-
 You can add variables that are set in the build environment to `.gitlab-ci.yml`.
 These variables are saved in the repository, and they
 are meant to store non-sensitive project configuration, like `RAILS_ENV` or
@@ -437,8 +434,7 @@ Once you set them, they are available for all subsequent pipelines. Any group-le
 
 Instance variables are useful for no longer needing to manually enter the same credentials repeatedly for all your projects. Instance-level variables are available to all projects and groups on the instance.
 
-NOTE: **Note:**
-The maximum number of instance-level variables is [planned to be 25](https://gitlab.com/gitlab-org/gitlab/-/issues/216097).
+In GitLab 13.1 and later, the [maximum number of instance-level variables is 25](https://gitlab.com/gitlab-org/gitlab/-/issues/216097).
 
 You can define instance-level variables via the UI or [API](../../api/instance_level_ci_variables.md).
 

doc/ci/variables/deprecated_variables.md

@@ -16,7 +16,6 @@ To follow conventions of naming across GitLab, and to further move away from the
 `build` term and toward `job`, some [CI/CD environment variables](README.md#predefined-environment-variables) were renamed for GitLab 9.0
 release.
 
-NOTE: **Note:**
 Starting with GitLab 9.0, we have deprecated the `$CI_BUILD_*` variables. **You are
 strongly advised to use the new variables as we will remove the old ones in
 future GitLab releases.**

doc/ci/variables/where_variables_can_be_used.md

@@ -38,15 +38,14 @@ There are two places defined variables can be used. On the:
 
 ### `config.toml` file
 
-NOTE: **Note:**
-You can read more about `config.toml` in the [GitLab Runner docs](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
-
 | Definition                           | Can be expanded? | Description                                                                                                                                  |
 |:-------------------------------------|:-----------------|:---------------------------------------------------------------------------------------------------------------------------------------------|
 | `runners.environment`                | yes              | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |
 | `runners.kubernetes.pod_labels`      | yes              | The Variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |
 | `runners.kubernetes.pod_annotations` | yes              | The Variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |
 
+You can read more about `config.toml` in the [GitLab Runner docs](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
+
 ## Expansion mechanisms
 
 There are three expansion mechanisms:
@@ -104,10 +103,6 @@ These restrictions are because `after_script` scripts are executed in a
 
 ## Persisted variables
 
-NOTE: **Note:**
-Some of the persisted variables contain tokens and cannot be used by some definitions
-due to security reasons.
-
 The following variables are known as "persisted":
 
 - `CI_PIPELINE_ID`
@@ -130,6 +125,9 @@ They are:
   - For definitions where the ["Expansion place"](#gitlab-ciyml-file) is GitLab.
   - In the `only` and `except` [variables expressions](README.md#environment-variables-expressions).
 
+Some of the persisted variables contain tokens and cannot be used by some definitions
+due to security reasons.
+
 ## Variables with an environment scope
 
 Variables defined with an environment scope are supported. Given that