Skip to content

G
gitlab-ce
Commit e06b6493 authored by Marcel Amirault's avatar Marcel Amirault Committed by Evan Read
Browse files
Options

Remove more reference links from ci docs 

Removes final cases of markdown reference links
from ci docs.
parent 8408c1bf
Hide whitespace changes
Inline Side-by-side
Showing with 71 additions and 153 deletions
doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
View file @ e06b6493
......@@ -16,7 +16,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
![Create project](img/external_repository.png)
GitLab will import the repository and enable [Pull Mirroring][pull-mirroring].
GitLab will import the repository and enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter).
1. In GitLab create a
[Personal Access Token](../../user/profile/personal_access_tokens.md)
......@@ -151,8 +151,6 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
GitLab is now configured to mirror changes from Bitbucket, run CI/CD pipelines
configured in `.gitlab-ci.yml` and push the status to Bitbucket.
[pull-mirroring]: ../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
......
doc/ci/ci_cd_for_external_repos/index.md
View file @ e06b6493
......@@ -4,7 +4,7 @@ type: index, howto
# GitLab CI/CD for external repositories **(PREMIUM)**
>[Introduced][ee-4642] in [GitLab Premium][eep] 10.6.
>[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4642) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.6.
GitLab CI/CD can be used with:
......@@ -15,10 +15,10 @@ GitLab CI/CD can be used with:
Instead of moving your entire project to GitLab, you can connect your
external repository to get the benefits of GitLab CI/CD.
Connecting an external repository will set up [repository mirroring][mirroring]
Connecting an external repository will set up [repository mirroring](../../user/project/repository/repository_mirroring.md)
and create a lightweight project with issues, merge requests, wiki, and
snippets disabled. These features
[can be re-enabled later][settings].
[can be re-enabled later](../../user/project/settings/index.md#sharing-and-permissions).
To connect to an external repository:
......@@ -94,8 +94,3 @@ references an open Pull Request, both will contribute to the status of the Pull
via GitHub integration. If you want to exclusively run pipelines on external pull
requests and not on branches you can add `except: [branches]` to the job specs.
[Read more](https://gitlab.com/gitlab-org/gitlab/issues/24089#workaround).
[ee-4642]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4642
[eep]: https://about.gitlab.com/pricing/
[mirroring]: ../../user/project/repository/repository_mirroring.md
[settings]: ../../user/project/settings/index.md#sharing-and-permissions
doc/ci/docker/using_docker_images.md
View file @ e06b6493
......@@ -9,7 +9,7 @@ GitLab CI/CD in conjunction with [GitLab Runner](../runners/README.md) can use
Docker is an open-source project that allows you to use predefined images to
run applications in independent "containers" that are run within a single Linux
instance. [Docker Hub][hub] has a rich database of pre-built images that can be
instance. [Docker Hub](https://hub.docker.com/) has a rich database of pre-built images that can be
used to test and build your applications.
When used with GitLab CI/CD, Docker runs each job in a separate and isolated
......@@ -23,7 +23,7 @@ test them on a dedicated CI server.
## Register Docker Runner
To use GitLab Runner with Docker you need to [register a new Runner][register]
To use GitLab Runner with Docker you need to [register a new Runner](https://docs.gitlab.com/runner/register/)
to use the `docker` executor.
A one-line example can be seen below:
......@@ -48,12 +48,12 @@ accessible during the build process.
The `image` keyword is the name of the Docker image the Docker executor
will run to perform the CI tasks.
By default, the executor will only pull images from [Docker Hub][hub],
By default, the executor will only pull images from [Docker Hub](https://hub.docker.com/),
however this can be configured in the `gitlab-runner/config.toml` by setting
the [Docker pull policy][] to allow using local images.
the [Docker pull policy](https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work) to allow using local images.
For more information about images and Docker Hub, please read
the [Docker Fundamentals][] documentation.
the [Docker Fundamentals](https://docs.docker.com/engine/understanding-docker/) documentation.
## What is a service
......@@ -68,7 +68,7 @@ time the project is built.
You are not limited to have only database services. You can add as many
services you need to `.gitlab-ci.yml` or manually modify `config.toml`.
Any image found at [Docker Hub][hub] or your private Container Registry can be
Any image found at [Docker Hub](https://hub.docker.com/) or your private Container Registry can be
used as a service.
Services inherit the same DNS servers, search domains, and additional hosts as
......@@ -80,7 +80,7 @@ You can see some widely used services examples in the relevant documentation of
### How services are linked to the job
To better understand how the container linking works, read
[Linking containers together][linking-containers].
[Linking containers together](https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/).
To summarize, if you add `mysql` as service to your application, the image will
then be used to create a container that is linked to the job container.
......@@ -156,7 +156,7 @@ either:
Let's say that you need a Wordpress instance to test some API integration with
your application.
You can then use for example the [tutum/wordpress][] image in your
You can then use for example the [tutum/wordpress](https://hub.docker.com/r/tutum/wordpress/) image in your
`.gitlab-ci.yml`:
```yaml
......@@ -332,7 +332,7 @@ For example, the following two definitions are equal:
| Setting | Required | GitLab version | Description |
|------------|----------|----------------| ----------- |
| `name` | yes, when used with any other option | 9.4 |Full name of the image that should be used. It should contain the Registry part if needed. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`][entrypoint] directive, where each shell token is a separate string in the array. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
### Available settings for `services`
......@@ -341,8 +341,8 @@ For example, the following two definitions are equal:
| Setting | Required | GitLab version | Description |
|------------|----------|----------------| ----------- |
| `name` | yes, when used with any other option | 9.4 | Full name of the image that should be used. It should contain the Registry part if needed. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`][entrypoint] directive, where each shell token is a separate string in the array. |
| `command` | no | 9.4 |Command or script that should be used as the container's command. It will be translated to arguments passed to Docker after the image's name. The syntax is similar to [`Dockerfile`'s `CMD`][cmd] directive, where each shell token is a separate string in the array. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
| `command` | no | 9.4 |Command or script that should be used as the container's command. It will be translated to arguments passed to Docker after the image's name. The syntax is similar to [`Dockerfile`'s `CMD`](https://docs.docker.com/engine/reference/builder/#cmd) directive, where each shell token is a separate string in the array. |
| `alias` | no | 9.4 |Additional alias that can be used to access the service from the job's container. Read [Accessing the services](#accessing-the-services) for more information. |
NOTE: **Note:**
......@@ -420,7 +420,7 @@ services:
command: ["/usr/bin/super-sql", "run"]
```
As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`][cmd].
As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`](https://docs.docker.com/engine/reference/builder/#cmd).
### Overriding the entrypoint of an image
......@@ -449,7 +449,7 @@ you should check which one your Runner is using. Specifically:
- If Docker 17.03 or previous versions are used, the `entrypoint` can be set to
`/bin/sh -c`, `/bin/bash -c` or an equivalent shell available in the image.
The syntax of `image:entrypoint` is similar to [Dockerfile's `ENTRYPOINT`][entrypoint].
The syntax of `image:entrypoint` is similar to [Dockerfile's `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint).
Let's assume you have a `super/sql:experimental` image with some SQL database
inside it and you would like to use it as a base image for your job because you
......@@ -836,14 +836,3 @@ docker rm -f -v build service-mysql service-postgres
This will forcefully (`-f`) remove the `build` container, the two service
containers as well as all volumes (`-v`) that were created with the container
creation.
[Docker Fundamentals]: https://docs.docker.com/engine/understanding-docker/
[docker pull policy]: https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work
[hub]: https://hub.docker.com/
[linking-containers]: https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/
[tutum/wordpress]: https://hub.docker.com/r/tutum/wordpress/
[postgres-hub]: https://hub.docker.com/r/_/postgres/
[mysql-hub]: https://hub.docker.com/r/_/mysql/
[entrypoint]: https://docs.docker.com/engine/reference/builder/#entrypoint
[cmd]: https://docs.docker.com/engine/reference/builder/#cmd
[register]: https://docs.gitlab.com/runner/register/
doc/ci/examples/php.md
View file @ e06b6493
......@@ -13,7 +13,7 @@ using the Shell executor.
While it is possible to test PHP apps on any system, this would require manual
configuration from the developer. To overcome this we will be using the
official [PHP docker image][php-hub] that can be found in Docker Hub.
official [PHP docker image](https://hub.docker.com/_/php) that can be found in Docker Hub.
This will allow us to test PHP projects against different versions of PHP.
However, not everything is plug 'n' play, you still need to configure some
......@@ -170,12 +170,12 @@ Finally, push to GitLab and let the tests begin!
### Test against different PHP versions in Shell builds
The [phpenv][] project allows you to easily manage different versions of PHP
The [phpenv](https://github.com/phpenv/phpenv) project allows you to easily manage different versions of PHP
each with its own config. This is especially useful when testing PHP projects
with the Shell executor.
You will have to install it on your build machine under the `gitlab-runner`
user following [the upstream installation guide][phpenv-installation].
user following [the upstream installation guide](https://github.com/phpenv/phpenv#installation).
Using phpenv also allows to easily configure the PHP environment with:
......@@ -279,14 +279,9 @@ gitlab-runner exec shell test:app
## Example project
We have set up an [Example PHP Project][php-example-repo] for your convenience
We have set up an [Example PHP Project](https://gitlab.com/gitlab-examples/php) for your convenience
that runs on [GitLab.com](https://gitlab.com) using our publicly available
[shared runners](../runners/README.md).
Want to hack on it? Simply fork it, commit, and push your changes. Within a few
moments the changes will be picked by a public runner and the job will begin.
[php-hub]: https://hub.docker.com/_/php
[phpenv]: https://github.com/phpenv/phpenv
[phpenv-installation]: https://github.com/phpenv/phpenv#installation
[php-example-repo]: https://gitlab.com/gitlab-examples/php
doc/ci/git_submodules.md
View file @ e06b6493
......@@ -14,11 +14,11 @@ type: reference
> - With GitLab 8.12 onward, your permissions are used to evaluate what a CI job
> can access. More information about how this system works can be found in the
> [Jobs permissions model](../user/permissions.md#job-permissions).
> - The HTTP(S) Git protocol [must be enabled][gitpro] in your GitLab instance.
> - The HTTP(S) Git protocol [must be enabled](../user/admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols) in your GitLab instance.
## Configuring the `.gitmodules` file
If dealing with [Git submodules][gitscm], your project will probably have a file
If dealing with [Git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules), your project will probably have a file
named `.gitmodules`.
Let's consider the following example:
......@@ -98,7 +98,3 @@ remote URL. On subsequent jobs on the same Runner, `.git/config` is cached
and already contains a full URL for the submodule, corresponding to the previous
job, and to **a token from a previous job**. `sync` allows to force updating
the full URL.
[gitpro]: ../user/admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols
[gitscm]: https://git-scm.com/book/en/v2/Git-Tools-Submodules "Git submodules documentation"
[newperms]: ../user/project/new_ci_build_permissions_model.md
doc/ci/pipelines/job_artifacts.md
View file @ e06b6493
......@@ -52,12 +52,12 @@ For more examples on artifacts, follow the [artifacts reference in
## Browsing artifacts
> - From GitLab 9.2, PDFs, images, videos and other formats can be previewed directly in the job artifacts browser without the need to download them.
> - Introduced in [GitLab 10.1][ce-14399], HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
> - Introduced in [GitLab 12.4][gitlab-16675], artifacts in private projects can be previewed when [GitLab Pages access control](../../administration/pages/index.md#access-control) is enabled.
> - Introduced in [GitLab 10.1](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14399), HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
> - Introduced in [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16675), artifacts in private projects can be previewed when [GitLab Pages access control](../../administration/pages/index.md#access-control) is enabled.
After a job finishes, if you visit the job's specific page, there are three
buttons. You can download the artifacts archive or browse its contents, whereas
the **Keep** button appears only if you have set an [expiry date] to the
the **Keep** button appears only if you have set an [expiry date](../yaml/README.md#artifactsexpire_in) to the
artifacts in case you changed your mind and want to keep them.
![Job artifacts browser button](img/job_artifacts_browser_button.png)
......@@ -198,10 +198,6 @@ To erase a job:
In order to retrieve a job artifact of a different project, you might need to use a private token in order to [authenticate and download](../../api/jobs.md#get-job-artifacts) the artifacts.
[expiry date]: ../yaml/README.md#artifactsexpire_in
[ce-14399]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14399
[gitlab-16675]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16675
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
......
doc/ci/quick_start/README.md
View file @ e06b6493
......@@ -6,7 +6,7 @@ type: reference
NOTE: **Note:**
Starting from version 8.0, GitLab [Continuous Integration](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) (CI)
is fully integrated into GitLab itself and is [enabled] by default on all
is fully integrated into GitLab itself and is [enabled](../enable_or_disable_ci.md) by default on all
projects.
NOTE: **Note:**
......@@ -75,7 +75,7 @@ Because `.gitlab-ci.yml` is in the repository and is version controlled, old
versions still build successfully, forks can easily make use of CI, branches can
have different pipelines and jobs, and you have a single source of truth for CI.
You can read more about the reasons why we are using `.gitlab-ci.yml` [in our
blog about it][blog-ci].
blog about it](https://about.gitlab.com/blog/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/).
### Creating a simple `.gitlab-ci.yml` file
......@@ -183,7 +183,7 @@ can be found at <https://docs.gitlab.com/runner/>.
In order to have a functional Runner you need to follow two steps:
1. [Install it][runner-install]
1. [Install it](https://docs.gitlab.com/runner/install/)
1. [Configure it](../runners/README.md#registering-a-specific-runner)
Follow the links above to set up your own Runner or use a Shared Runner as
......@@ -231,10 +231,5 @@ GitLab, such as **Commits** and **Merge requests**.
## Examples
Visit the [examples README][examples] to see a list of examples using GitLab
Visit the [examples README](../examples/README.md) to see a list of examples using GitLab
CI with various languages.
[runner-install]: https://docs.gitlab.com/runner/install/
[blog-ci]: https://about.gitlab.com/blog/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/
[examples]: ../examples/README.md
[enabled]: ../enable_or_disable_ci.md
doc/ci/runners/README.md
View file @ e06b6493
......@@ -17,7 +17,7 @@ for more information.
## Shared, specific and group Runners
After [installing the Runner][install], you can either register it as shared or
After [installing the Runner](https://docs.gitlab.com/runner/install/), you can either register it as shared or
specific. You can only register a shared Runner if you have admin access to
the GitLab instance. The main differences between a shared and a specific Runner
are:
......@@ -35,10 +35,10 @@ are:
up the specific Runner with this in mind, while not having to do this for all
Runners. For example, if you want to deploy a certain project, you can set up
a specific Runner to have the right credentials for this. The [usage of tags](#using-tags)
may be useful in this case. Specific Runners process jobs using a [FIFO] queue.
may be useful in this case. Specific Runners process jobs using a [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) queue.
- **Group Runners** are useful when you have multiple projects under one group
and would like all projects to have access to a set of Runners. Group Runners
process jobs using a [FIFO] queue.
process jobs using a [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) queue.
A Runner that is specific only runs for the specified project(s). A shared Runner
can run jobs for every project that has enabled the option **Allow shared Runners**
......@@ -64,7 +64,7 @@ You can only register a shared Runner if you are an admin of the GitLab instance
![Shared Runners Admin Area](img/shared_runners_admin.png)
1. [Register the Runner][register]
1. [Register the Runner](https://docs.gitlab.com/runner/register/)
Shared Runners are enabled by default as of GitLab 8.2, but can be disabled
with the **Disable shared Runners** button which is present under each project's
......@@ -84,7 +84,7 @@ To create a specific Runner without having admin rights to the GitLab instance,
visit the project you want to make the Runner work for in GitLab:
1. Go to **Settings > CI/CD** to obtain the token
1. [Register the Runner][register]
1. [Register the Runner](https://docs.gitlab.com/runner/register/)
## Registering a group Runner
......@@ -92,7 +92,7 @@ Creating a group Runner requires Owner permissions for the group. To create a
group Runner visit the group you want to make the Runner work for in GitLab:
1. Go to **Settings > CI/CD** to obtain the token
1. [Register the Runner][register]
1. [Register the Runner](https://docs.gitlab.com/runner/register/)
### Making an existing shared Runner specific
......@@ -111,7 +111,7 @@ From now on, the shared Runner will be specific to those projects.
You can configure a Runner to assign it exclusively to a project. When a
Runner is locked this way, it can no longer be enabled for other projects.
This setting can be enabled the first time you [register a Runner][register] and
This setting can be enabled the first time you [register a Runner](https://docs.gitlab.com/runner/register/) and
can be changed afterwards under each Runner's settings.
To lock/unlock a Runner:
......@@ -160,7 +160,7 @@ An admin can enable/disable a specific Runner for projects:
You can protect Runners from revealing sensitive information.
Whenever a Runner is protected, the Runner picks only jobs created on
[protected branches] or [protected tags], and ignores other jobs.
[protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md), and ignores other jobs.
To protect/unprotect Runners:
......@@ -245,7 +245,7 @@ the appropriate dependencies to run Rails test suites.
### Allowing Runners with tags to pick jobs without tags
When you [register a Runner][register], its default behavior is to **only pick**
When you [register a Runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
[tagged jobs](../yaml/README.md#tags).
NOTE: **Note:**
......@@ -305,7 +305,7 @@ Example 2:
### Setting maximum job timeout for a Runner
For each Runner you can specify a _maximum job timeout_. Such timeout,
if smaller than [project defined timeout], will take the precedence. This
if smaller than [project defined timeout](../pipelines/settings.md#timeout), will take the precedence. This
feature can be used to prevent Shared Runner from being appropriated
by a project by setting a ridiculous big timeout (for example, one week).
......@@ -416,10 +416,3 @@ You can find the IP address of a Runner for a specific project by:
1. On the details page you should see a row for "IP Address"
![specific Runner IP address](img/specific_runner_ip_address.png)
[install]: https://docs.gitlab.com/runner/install/
[fifo]: https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)
[register]: https://docs.gitlab.com/runner/register/
[protected branches]: ../../user/project/protected_branches.md
[protected tags]: ../../user/project/protected_tags.md
[project defined timeout]: ../pipelines/settings.md#timeout
doc/ci/services/docker-services.md
View file @ e06b6493
---
redirect_to: 'README.md'
---
This document was moved to [another location](README.md).
doc/ci/services/postgres.md
View file @ e06b6493
......@@ -45,11 +45,11 @@ Database: nice_marmot
If you are wondering why we used `postgres` for the `Host`, read more at
[How services are linked to the job](../docker/using_docker_images.md#how-services-are-linked-to-the-job).
You can also use any other docker image available on [Docker Hub][hub-pg].
You can also use any other docker image available on [Docker Hub](https://hub.docker.com/_/postgres).
For example, to use PostgreSQL 9.3 the service becomes `postgres:9.3`.
The `postgres` image can accept some environment variables. For more details
check the documentation on [Docker Hub][hub-pg].
check the documentation on [Docker Hub](https://hub.docker.com/_/postgres).
## Use PostgreSQL with the Shell executor
......@@ -115,12 +115,9 @@ Database: nice_marmot
## Example project
We have set up an [Example PostgreSQL Project][postgres-example-repo] for your
We have set up an [Example PostgreSQL Project](https://gitlab.com/gitlab-examples/postgres) for your
convenience that runs on [GitLab.com](https://gitlab.com) using our publicly
available [shared runners](../runners/README.md).
Want to hack on it? Simply fork it, commit and push your changes. Within a few
moments the changes will be picked by a public runner and the job will begin.
[hub-pg]: https://hub.docker.com/_/postgres
[postgres-example-repo]: https://gitlab.com/gitlab-examples/postgres
doc/ci/ssh_keys/README.md
View file @ e06b6493
......@@ -204,11 +204,9 @@ before_script:
## Example project
We have set up an [Example SSH Project][ssh-example-repo] for your convenience
We have set up an [Example SSH Project](https://gitlab.com/gitlab-examples/ssh-private-key/) for your convenience
that runs on [GitLab.com](https://gitlab.com) using our publicly available
[shared runners](../runners/README.md).
Want to hack on it? Simply fork it, commit and push your changes. Within a few
moments the changes will be picked by a public runner and the job will begin.
[ssh-example-repo]: https://gitlab.com/gitlab-examples/ssh-private-key/
doc/ci/triggers/README.md
View file @ e06b6493
......@@ -29,12 +29,12 @@ to protect trigger tokens.
### CI job token
You can use the `CI_JOB_TOKEN` [variable][predef] (used to authenticate
with the [GitLab Container Registry][registry]) in the following cases.
You can use the `CI_JOB_TOKEN` [variable](../variables/README.md#predefined-environment-variables) (used to authenticate
with the [GitLab Container Registry](../../user/packages/container_registry/index.md)) in the following cases.
#### When used with multi-project pipelines
> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [introduced][ee-2017] in [GitLab Premium][ee] 9.3.
> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2017) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.3.
> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [made available](https://gitlab.com/gitlab-org/gitlab/issues/31573) in all tiers in GitLab 12.4.
This way of triggering can only be used when invoked inside `.gitlab-ci.yml`,
......@@ -53,11 +53,11 @@ build_docs:
Pipelines triggered that way also expose a special variable:
`CI_PIPELINE_SOURCE=pipeline`.
Read more about the [pipelines trigger API][trigapi].
Read more about the [pipelines trigger API](../../api/pipeline_triggers.md).
#### When a pipeline depends on the artifacts of another pipeline **(PREMIUM)**
> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346] in [GitLab Premium][ee] 9.5.
> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2346) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.5.
With the introduction of dependencies between different projects, one of
them may need to access artifacts created by a previous one. This process
......@@ -78,7 +78,7 @@ build_submodule:
This allows you to use that for multi-project pipelines and download artifacts
from any project to which you have access as this follows the same principles
with the [permission model][permissions].
with the [permission model](../../user/permissions.md#job-permissions).
Read more about the [jobs API](../../api/jobs.md#download-the-artifacts-archive).
......@@ -273,12 +273,3 @@ Old triggers, created before GitLab 9.0 will be marked as legacy.
Triggers with the legacy label do not have an associated user and only have
access to the current project. They are considered deprecated and will be
removed with one of the future versions of GitLab.
[ee-2017]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2017
[ee-2346]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2346
[ee]: https://about.gitlab.com/pricing/
[variables]: ../variables/README.md
[predef]: ../variables/README.md#predefined-environment-variables
[registry]: ../../user/packages/container_registry/index.md
[permissions]: ../../user/permissions.md#job-permissions
[trigapi]: ../../api/pipeline_triggers.md
doc/ci/variables/README.md
View file @ e06b6493
......@@ -221,7 +221,7 @@ All variables are set as environment variables in the build environment, and
they are accessible with normal methods that are used to access such variables.
In most cases `bash` or `sh` is used to execute the job script.
To access environment variables, use the syntax for your Runner's [shell][shellexecutors].
To access environment variables, use the syntax for your Runner's [shell](https://docs.gitlab.com/runner/executors/).
| Shell | Usage |
|----------------------|-----------------|
......@@ -415,7 +415,7 @@ Click [here](where_variables_can_be_used.md) for a section that describes where
Variables can be protected. Whenever a variable is
protected, it would only be securely passed to pipelines running on the
[protected branches] or [protected tags]. The other pipelines would not get any
[protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md). The other pipelines would not get any
protected variables.
Protected variables can be added by going to your project's
......@@ -427,7 +427,7 @@ Once you set them, they will be available for all subsequent pipelines.
### Limiting environment scopes of environment variables
You can limit the environment scope of a variable by
[defining which environments][envs] it can be available for.
[defining which environments](../environments.md) it can be available for.
To learn more about about scoping environments, see [Scoping environments with specs](../environments.md#scoping-environments-with-specs).
......@@ -802,15 +802,3 @@ if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
...
```
[ce-13784]: https://gitlab.com/gitlab-org/gitlab-foss/issues/13784 "Simple protection of CI variables"
[envs]: ../environments.md
[protected branches]: ../../user/project/protected_branches.md
[protected tags]: ../../user/project/protected_tags.md
[shellexecutors]: https://docs.gitlab.com/runner/executors/
[triggered]: ../triggers/README.md
[trigger-job-token]: ../triggers/README.md#ci-job-token
[gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
[registry]: ../../user/project/container_registry.md
[dependent-repositories]: ../../user/project/new_ci_build_permissions_model.md#dependent-repositories
[get-job-artifacts]: ../../api/jobs.html#get-job-artifacts
doc/ci/variables/predefined_variables.md
View file @ e06b6493
......@@ -45,8 +45,8 @@ future GitLab releases.**
| `CI_CONFIG_PATH` | 9.4 | 0.5 | The path to CI config file. Defaults to `.gitlab-ci.yml` |
| `CI_DEBUG_TRACE` | all | 1.7 | Whether [debug logging (tracing)](README.md#debug-logging) is enabled |
| `CI_DEFAULT_BRANCH` | 12.4 | all | The name of the default branch for the project. |
| `CI_DEPLOY_PASSWORD` | 10.8 | all | Authentication password of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related. |
| `CI_DEPLOY_USER` | 10.8 | all | Authentication username of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related. |
| `CI_DEPLOY_PASSWORD` | 10.8 | all | Authentication password of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), only present if the Project has one related. |
| `CI_DEPLOY_USER` | 10.8 | all | Authentication username of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), only present if the Project has one related. |
| `CI_DISPOSABLE_ENVIRONMENT` | all | 10.1 | Marks that the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). If the environment is disposable, it is set to true, otherwise it is not defined at all. |
| `CI_ENVIRONMENT_NAME` | 8.15 | all | The name of the environment for this job. Only present if [`environment:name`](../yaml/README.md#environmentname) is set. |
| `CI_ENVIRONMENT_SLUG` | 8.15 | all | A simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, etc. Only present if [`environment:name`](../yaml/README.md#environmentname) is set. |
......@@ -61,7 +61,7 @@ future GitLab releases.**
| `CI_JOB_MANUAL` | 8.12 | all | The flag to indicate that job was manually started |
| `CI_JOB_NAME` | 9.0 | 0.5 | The name of the job as defined in `.gitlab-ci.yml` |
| `CI_JOB_STAGE` | 9.0 | 0.5 | The name of the stage as defined in `.gitlab-ci.yml` |
| `CI_JOB_TOKEN` | 9.0 | 1.2 | Token used for authenticating with the [GitLab Container Registry][registry] and downloading [dependent repositories][dependent-repositories] |
| `CI_JOB_TOKEN` | 9.0 | 1.2 | Token used for authenticating with the [GitLab Container Registry](../../user/packages/container_registry/index.md) and downloading [dependent repositories](../../user/project/new_ci_build_permissions_model.md#dependent-repositories) |
| `CI_JOB_URL` | 11.1 | 0.5 | Job details URL |
| `CI_MERGE_REQUEST_ASSIGNEES` | 11.9 | all | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created. |
| `CI_MERGE_REQUEST_CHANGED_PAGE_PATHS` | 12.9 | all | Comma-separated list of paths of changed pages in a deployed [Review App](../review_apps/index.md) for a [Merge Request](../merge_request_pipelines/index.md). A [Route Map](../review_apps/index.md#route-maps) must be configured. |
......@@ -134,7 +134,3 @@ future GitLab releases.**
| `GITLAB_USER_LOGIN` | 10.0 | all | The login username of the user who started the job |
| `GITLAB_USER_NAME` | 10.0 | all | The real name of the user who started the job |
| `RESTORE_CACHE_ATTEMPTS` | 8.15 | 1.9 | Number of attempts to restore the cache running a job |
[gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
[registry]: ../../user/packages/container_registry/index.md
[dependent-repositories]: ../../user/project/new_ci_build_permissions_model.md#dependent-repositories
doc/ci/yaml/README.md
View file @ e06b6493
......@@ -543,7 +543,7 @@ In addition, `only` and `except` allow the use of special keywords:
| `external` | When using CI services other than GitLab. |
| `pipelines` | For multi-project triggers, created using the API with `CI_JOB_TOKEN`. |
| `pushes` | Pipeline is triggered by a `git push` by the user. |
| `schedules` | For [scheduled pipelines][schedules]. |
| `schedules` | For [scheduled pipelines](../pipelines/schedules.md). |
| `triggers` | For pipelines created using a trigger token. |
| `web` | For pipelines created using **Run pipeline** button in GitLab UI (under your project's **Pipelines**). |
| `merge_requests` | When a merge request is created or updated (See [pipelines for merge requests](../merge_request_pipelines/index.md)). |
......@@ -577,7 +577,7 @@ job:
```
In this example, `job` will run only for refs that are tagged, or if a build is
explicitly requested via an API trigger or a [Pipeline Schedule][schedules]:
explicitly requested via an API trigger or a [Pipeline Schedule](../pipelines/schedules.md):
```yaml
job:
......@@ -739,7 +739,7 @@ The `refs` strategy can take the same values as the
[simplified only/except configuration](#onlyexcept-basic).
In the example below, the `deploy` job is going to be created only when the
pipeline has been [scheduled][schedules] or runs for the `master` branch:
pipeline has been [scheduled](../pipelines/schedules.md) or runs for the `master` branch:
```yaml
deploy:
......@@ -800,7 +800,7 @@ Learn more about [variables expressions](../variables/README.md#environment-vari
#### `only:changes`/`except:changes`
> `changes` policy [introduced][ce-19232] in GitLab 11.4.
> `changes` policy [introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/19232) in GitLab 11.4.
Using the `changes` keyword with `only` or `except` makes it possible to define if
a job should be created based on files modified by a Git push event.
......@@ -1480,7 +1480,7 @@ GitLab Runner will pick your job soon and start the job.
> - Introduced in GitLab 8.9.
> - You can read more about environments and find more examples in the
> [documentation about environments][environment].
> [documentation about environments](../environments.md).
`environment` is used to define that a job deploys to a specific environment.
If `environment` is specified and no environment under that name exists, a new
......@@ -1562,7 +1562,7 @@ deploy to production:
#### `environment:on_stop`
> - [Introduced][ce-6669] in GitLab 8.13.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6669) in GitLab 8.13.
> - Starting with GitLab 8.14, when you have an environment that has a stop action
> defined, GitLab will automatically trigger a stop action when the associated
> branch is deleted.
......@@ -1575,7 +1575,7 @@ Read the `environment:action` section for an example.
#### `environment:action`
> [Introduced][ce-6669] in GitLab 8.13.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6669) in GitLab 8.13.
The `action` keyword is to be used in conjunction with `on_stop` and is defined
in the job that is called to close the environment.
......@@ -1682,8 +1682,8 @@ To follow progress on support for GitLab-managed clusters, see the
#### Dynamic environments
> - [Introduced][ce-6323] in GitLab 8.12 and GitLab Runner 1.6.
> - The `$CI_ENVIRONMENT_SLUG` was [introduced][ce-7983] in GitLab 8.15.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6323) in GitLab 8.12 and GitLab Runner 1.6.
> - The `$CI_ENVIRONMENT_SLUG` was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7983) in GitLab 8.15.
> - The `name` and `url` parameters can use any of the defined CI variables,
> including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
> You however cannot use variables defined under `script`.
......@@ -1701,7 +1701,7 @@ deploy as review app:
The `deploy as review app` job will be marked as deployment to dynamically
create the `review/$CI_COMMIT_REF_NAME` environment, where `$CI_COMMIT_REF_NAME`
is an [environment variable][variables] set by the Runner. The
is an [environment variable](../variables/README.md) set by the Runner. The
`$CI_ENVIRONMENT_SLUG` variable is based on the environment name, but suitable
for inclusion in URLs. In this case, if the `deploy as review app` job was run
in a branch named `pow`, this environment would be accessible with an URL like
......@@ -2652,7 +2652,7 @@ Downloading artifacts from jobs that are run in [`parallel:`](#parallel) is not
### `coverage`
> [Introduced][ce-7447] in GitLab 8.17.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7447) in GitLab 8.17.
`coverage` allows you to configure how code coverage will be extracted from the
job output.
......@@ -2672,7 +2672,7 @@ job1:
### `retry`
> - [Introduced][ce-12909] in GitLab 9.5.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909) in GitLab 9.5.
> - [Behaviour expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
`retry` allows you to configure how many times a job is going to be retried in
......@@ -3613,7 +3613,7 @@ which can be set in GitLab's UI.
[YAML anchors for variables](#yaml-anchors-for-variables) are available.
Learn more about [variables and their priority][variables].
Learn more about [variables and their priority](../variables/README.md).
#### Git strategy
......@@ -4202,14 +4202,3 @@ questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
[ce-6323]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6323
[ce-6669]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6669
[ce-7983]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7983
[ce-7447]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7447
[ce-12909]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909
[ce-19232]: https://gitlab.com/gitlab-org/gitlab-foss/issues/19232
[environment]: ../environments.md "CI/CD environments"
[schedules]: ../pipelines/schedules.md "Pipelines schedules"
[variables]: ../variables/README.md "CI/CD variables"
[push-option]: https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7