| `id` | integer/string | yes | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
| `job_id` | integer | yes | ID of a job. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers] for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline-premium) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
Example request using the `PRIVATE-TOKEN` header:
...
...
@@ -406,8 +406,8 @@ Possible response status codes:
> **Notes**:
>
> - [Introduced][ce-5347] in GitLab 8.10.
> - 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.
Download the artifacts zipped archive from the latest successful pipeline for
the given reference name and job, provided the job finished successfully. This
...
...
@@ -425,7 +425,7 @@ Parameters
| `id` | integer/string | yes | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
| `ref_name` | string | yes | Branch or tag name in repository. HEAD or SHA references are not supported. |
| `job` | string | yes | The name of the job. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers] for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
| `job_token`**(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline-premium) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
> [Introduced][ee-1659] in [GitLab Premium][eep] 9.1.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1659) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.1.
A popular [Continuous Deployment](https://en.wikipedia.org/wiki/Continuous_deployment)
strategy, where a small portion of the fleet is updated to the new version of
...
...
@@ -8,7 +8,7 @@ your application.
## Overview
When embracing [Continuous Delivery][cd-blog], a company needs to decide what
When embracing [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/), a company needs to decide what
type of deployment strategy to use. One of the most popular strategies is canary
deployments, where a small portion of the fleet is updated to the new version
first. This subset, the canaries, then serve as the proverbial
...
...
@@ -18,8 +18,8 @@ If there is a problem with the new version of the application, only a small
percentage of users are affected and the change can either be fixed or quickly
reverted.
Leveraging [Kubernetes' Canary deployments][kube-canary], visualize your canary
deployments right inside the [Deploy Board], without the need to leave GitLab.
Leveraging [Kubernetes' Canary deployments](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments), visualize your canary
deployments right inside the [Deploy Board](deploy_boards.md), without the need to leave GitLab.
## Use cases
...
...
@@ -35,7 +35,7 @@ to be careful when using canaries with user-facing changes, because by default,
requests from the same user will be randomly distributed between canary and
non-canary pods, which could result in confusion or even errors. If needed, you
may want to consider [setting `service.spec.sessionAffinity` to `ClientIP` in
your Kubernetes service definitions][kube-net], but that is beyond the scope of
your Kubernetes service definitions][kube-net](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), but that is beyond the scope of
this document.
## Enabling Canary Deployments
...
...
@@ -61,10 +61,3 @@ Canary deployments are marked with a yellow dot in the Deploy Board so that you
can easily notice them.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17894) in GitLab 10.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/issues/199370) from **Settings > Repository** in GitLab 12.9.
Deploy tokens allow you to download (`git clone`) or read the container registry images of a project without having a user and a password.
...
...
@@ -43,7 +43,7 @@ the following table.
| Scope | Description |
| ----- | ----------- |
| `read_repository` | Allows read-access to the repository through `git clone` |
| `read_registry` | Allows read-access to [container registry] images if a project is private and authorization is required. |
| `read_registry` | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. |
## Deploy token custom username
...
...
@@ -101,7 +101,7 @@ apply consistently when cloning the repository of related projects.
### GitLab Deploy Token
> [Introduced][ce-18414] in GitLab 10.8.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18414) in GitLab 10.8.
There's a special case when it comes to Deploy Tokens. If a user creates one
named `gitlab-deploy-token`, the username and token of the Deploy Token will be
@@ -32,7 +32,7 @@ as created by the pusher (local push or via the UI) and any job created in this
pipeline will have the read permissions of the pusher but not write permissions.
This allows us to make it really easy to evaluate the access for all projects
that have [Git submodules][gitsub] or are using container images that the pusher
that have [Git submodules](../../ci/git_submodules.md) or are using container images that the pusher
would have access too. **The permission is granted only for the time that the job
is running. The access is revoked after the job is finished.**
...
...
@@ -132,7 +132,7 @@ With the new job permissions model, there is now an easy way to access all
dependent source code in a project. That way, we can:
1. Access a project's dependent repositories
1. Access a project's [Git submodules][gitsub]
1. Access a project's [Git submodules](../../ci/git_submodules.md)
1. Access private container images
1. Access project's and submodule LFS objects
...
...
@@ -151,15 +151,15 @@ In short here's what you need to do should you encounter any issues.
As an administrator:
-**500 errors**: You will need to update [GitLab Workhorse][workhorse] to at
-**500 errors**: You will need to update [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) to at
least 0.8.2. This is done automatically for Omnibus installations, you need to
[check manually][update-docs] for installations from source.
[check manually](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/update) for installations from source.
-**500 errors**: Check if you have another web proxy sitting in front of NGINX (HAProxy,
Apache, etc.). It might be a good idea to let GitLab use the internal NGINX
web server and not disable it completely. See [this comment][comment] for an
web server and not disable it completely. See [this comment](https://gitlab.com/gitlab-org/gitlab-foss/issues/22484#note_16648302) for an
example.
-**403 errors**: You need to make sure that your installation has [HTTP(S)
cloning enabled][https]. HTTP(S) support is now a **requirement** by GitLab CI
cloning enabled](../admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols). HTTP(S) support is now a **requirement** by GitLab CI
to clone all sources.
As a user:
...
...
@@ -170,7 +170,7 @@ As a user:
### Dependent repositories
The [Job environment variable][jobenv]`CI_JOB_TOKEN` can be used to
The [Job environment variable](../../ci/variables/README.md#predefined-environment-variables)`CI_JOB_TOKEN` can be used to
authenticate any clones of dependent repositories. For example:
@@ -21,7 +21,7 @@ In brief, this is what you need to upload your website in GitLab Pages:
1. Domain of the instance: domain name that is used for GitLab Pages
(ask your administrator).
1. GitLab CI/CD: a `.gitlab-ci.yml` file with a specific job named [`pages`][pages] in the root directory of your repository.
1. GitLab CI/CD: a `.gitlab-ci.yml` file with a specific job named [`pages`](../../../ci/yaml/README.md#pages) in the root directory of your repository.
1. A directory called `public` in your site's repo containing the content
to be published.
1. GitLab Runner enabled for the project.
...
...
@@ -61,7 +61,7 @@ If the case of `404.html`, there are different scenarios. For example:
Since you cannot use any custom server configuration files, like `.htaccess` or
any `.conf` file, if you want to redirect a page to another
location, you can use the [HTTP meta refresh tag][metarefresh].
location, you can use the [HTTP meta refresh tag](https://en.wikipedia.org/wiki/Meta_refresh).
Some static site generators provide plugins for that functionality so that you
don't have to create and edit HTML files manually. For example, Jekyll has the
...
...
@@ -286,8 +286,4 @@ No, you don't. You can create your project first and it will be accessed under
## Known issues
For a list of known issues, visit GitLab's [public issue tracker].
