diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-12 03:08:55 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-12 03:08:55 +0000 |
commit | 500626a5c953ad81cfc3ed74bf0148c075617e58 (patch) | |
tree | 554e385e0e548f15fc90388da8b73622b803d6f3 /doc/ci | |
parent | b133cb2468b412683dbc5f19492d98b2ffa47d09 (diff) | |
download | gitlab-ce-500626a5c953ad81cfc3ed74bf0148c075617e58.tar.gz |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/ci')
-rw-r--r-- | doc/ci/docker/using_docker_images.md | 2 | ||||
-rw-r--r-- | doc/ci/variables/predefined_variables.md | 2 | ||||
-rw-r--r-- | doc/ci/yaml/README.md | 8 |
3 files changed, 6 insertions, 6 deletions
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 018e0c4b84d..621b679de73 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -642,7 +642,7 @@ Specifying only `registry.example.com` will not work. ### Configuring a Runner If you have many pipelines that access the same registry, it'll -probably be better to setup registry access at the runner level. This +probably be better to setup registry access at the runner level. This allows pipeline authors to have access to a private registry just by running a job on the appropriate runner. It also makes registry changes and credential rotations much simpler. diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md index 5cc93427d42..dd15b8c37b1 100644 --- a/doc/ci/variables/predefined_variables.md +++ b/doc/ci/variables/predefined_variables.md @@ -99,7 +99,7 @@ future GitLab releases.** | `CI_PROJECT_TITLE` | 12.4 | all | The human-readable project name as displayed in the GitLab web interface. | | `CI_PROJECT_URL` | 8.10 | 0.5 | The HTTP(S) address to access project | | `CI_PROJECT_VISIBILITY` | 10.3 | all | The project visibility (internal, private, public) | -| `CI_REGISTRY` | 8.10 | 0.5 | If the Container Registry is enabled it returns the address of GitLab's Container Registry. This variable will include a `:port` value if one has been specified in the registry configuration. | +| `CI_REGISTRY` | 8.10 | 0.5 | If the Container Registry is enabled it returns the address of GitLab's Container Registry. This variable will include a `:port` value if one has been specified in the registry configuration. | | `CI_REGISTRY_IMAGE` | 8.10 | 0.5 | If the Container Registry is enabled for the project it returns the address of the registry tied to the specific project | | `CI_REGISTRY_PASSWORD` | 9.0 | all | The password to use to push containers to the GitLab Container Registry | | `CI_REGISTRY_USER` | 9.0 | all | The username to use to push containers to the GitLab Container Registry | diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 881f3297695..a516a3f56f7 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1523,7 +1523,7 @@ globally and all jobs will use that definition. Use the `paths` directive to choose which files or directories will be cached. Paths are relative to the project directory (`$CI_PROJECT_DIR`) and cannot directly link outside it. Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) -patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match). +patterns and [`filepath.Match`](https://golang.org/pkg/path/filepath/#Match). Cache all files in `binaries` that end in `.apk` and the `.config` file: @@ -1755,7 +1755,7 @@ be available for download in the GitLab UI. Paths are relative to the project directory (`$CI_PROJECT_DIR`) and cannot directly link outside it. Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) -patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match). +patterns and [`filepath.Match`](https://golang.org/pkg/path/filepath/#Match). To restrict which jobs a specific job will fetch artifacts from, see [dependencies](#dependencies). @@ -3212,9 +3212,9 @@ spinach: ``` In GitLab 12.0 and later, it's also possible to use multiple parents for -`extends`. The algorithm used for merge is "closest scope wins", so +`extends`. The algorithm used for merge is "closest scope wins", so keys from the last member will always shadow anything defined on other -levels. For example: +levels. For example: ```yaml .only-important: |