Commit 8272b0c8 authored by Marcel Amirault's avatar Marcel Amirault Committed by Evan Read

Docs: Fix CI/CD related anchors

parent f2a53ee4
...@@ -48,7 +48,7 @@ into more features: ...@@ -48,7 +48,7 @@ into more features:
| [Introduction to pipelines and jobs](pipelines.md) | Provides an overview of GitLab CI/CD and jobs. | | [Introduction to pipelines and jobs](pipelines.md) | Provides an overview of GitLab CI/CD and jobs. |
| [CI/CD Variables](variables/README.md) | How environment variables can be configured and made available in pipelines. | | [CI/CD Variables](variables/README.md) | How environment variables can be configured and made available in pipelines. |
| [Where variables can be used](variables/where_variables_can_be_used.md) | A deeper look into where and how CI/CD variables can be used. | | [Where variables can be used](variables/where_variables_can_be_used.md) | A deeper look into where and how CI/CD variables can be used. |
| [User](../user/permissions.md#gitlab-ci) and [job](../user/permissions.md#job-permissions) permissions | Learn about the access levels a user can have for performing certain CI actions. | | [User](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions | Learn about the access levels a user can have for performing certain CI actions. |
| [Configuring GitLab Runners](runners/README.md) | Documentation for configuring [GitLab Runner](https://docs.gitlab.com/runner/). | | [Configuring GitLab Runners](runners/README.md) | Documentation for configuring [GitLab Runner](https://docs.gitlab.com/runner/). |
| [Introduction to environments and deployments](environments.md) | Learn how to separate your jobs into environments and use them for different purposes like testing, building and, deploying. | | [Introduction to environments and deployments](environments.md) | Learn how to separate your jobs into environments and use them for different purposes like testing, building and, deploying. |
| [Job artifacts](../user/project/pipelines/job_artifacts.md) | Learn about the output of jobs. | | [Job artifacts](../user/project/pipelines/job_artifacts.md) | Learn about the output of jobs. |
......
...@@ -4,6 +4,7 @@ author_gitlab: blitzgren ...@@ -4,6 +4,7 @@ author_gitlab: blitzgren
level: intermediate level: intermediate
article_type: tutorial article_type: tutorial
date: 2018-03-07 date: 2018-03-07
last_updated: 2019-03-06
--- ---
# DevOps and Game Dev with GitLab CI/CD # DevOps and Game Dev with GitLab CI/CD
...@@ -520,7 +521,7 @@ a lot of breathing room in quickly getting changes to players. ...@@ -520,7 +521,7 @@ a lot of breathing room in quickly getting changes to players.
Here are some ideas to further investigate that can speed up or improve your pipeline: Here are some ideas to further investigate that can speed up or improve your pipeline:
- [Yarn](https://yarnpkg.com) instead of npm - [Yarn](https://yarnpkg.com) instead of npm
- Set up a custom [Docker](../../../ci/docker/using_docker_images.md#define-image-and-services-from-gitlab-ci-yml) image that can preload dependencies and tools (like AWS CLI) - Set up a custom [Docker](../../../ci/docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml) image that can preload dependencies and tools (like AWS CLI)
- Forward a [custom domain](http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) to your game's S3 static website - Forward a [custom domain](http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) to your game's S3 static website
- Combine jobs if you find it unnecessary for a small project - Combine jobs if you find it unnecessary for a small project
- Avoid the queues and set up your own [custom GitLab CI/CD runner](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) - Avoid the queues and set up your own [custom GitLab CI/CD runner](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/)
...@@ -5,6 +5,7 @@ author_gitlab: mehranrasulian ...@@ -5,6 +5,7 @@ author_gitlab: mehranrasulian
level: intermediate level: intermediate
article_type: tutorial article_type: tutorial
date: 2017-08-31 date: 2017-08-31
last_updated: 2019-03-06
--- ---
# Test and deploy Laravel applications with GitLab CI/CD and Envoy # Test and deploy Laravel applications with GitLab CI/CD and Envoy
...@@ -374,7 +375,7 @@ You might want to create another Envoy task to do that for you. ...@@ -374,7 +375,7 @@ You might want to create another Envoy task to do that for you.
We also create the `.env` file in the same path to set up our production environment variables for Laravel. We also create the `.env` file in the same path to set up our production environment variables for Laravel.
These are persistent data and will be shared to every new release. These are persistent data and will be shared to every new release.
Now, we would need to deploy our app by running `envoy run deploy`, but it won't be necessary since GitLab can handle that for us with CI's [environments](../../environments.md), which will be described [later](#setting-up-gitlab-ci-cd) in this tutorial. Now, we would need to deploy our app by running `envoy run deploy`, but it won't be necessary since GitLab can handle that for us with CI's [environments](../../environments.md), which will be described [later](#setting-up-gitlab-cicd) in this tutorial.
Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Envoy.blade.php) and push it to the `master` branch. Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Envoy.blade.php) and push it to the `master` branch.
To keep things simple, we commit directly to `master`, without using [feature-branches](../../../workflow/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial. To keep things simple, we commit directly to `master`, without using [feature-branches](../../../workflow/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial.
...@@ -557,7 +558,7 @@ So we should adjust the configuration of MySQL instance by defining `MYSQL_DATAB ...@@ -557,7 +558,7 @@ So we should adjust the configuration of MySQL instance by defining `MYSQL_DATAB
Find out more about MySQL variables at the [official MySQL Docker Image](https://hub.docker.com/r/_/mysql/). Find out more about MySQL variables at the [official MySQL Docker Image](https://hub.docker.com/r/_/mysql/).
Also set the variables `DB_HOST` to `mysql` and `DB_USERNAME` to `root`, which are Laravel specific variables. Also set the variables `DB_HOST` to `mysql` and `DB_USERNAME` to `root`, which are Laravel specific variables.
We define `DB_HOST` as `mysql` instead of `127.0.0.1`, as we use MySQL Docker image as a service which [is linked to the main Docker image](../../docker/using_docker_images.md#how-services-are-linked-to-the-build). We define `DB_HOST` as `mysql` instead of `127.0.0.1`, as we use MySQL Docker image as a service which [is linked to the main Docker image](../../docker/using_docker_images.md#how-services-are-linked-to-the-job).
```yaml ```yaml
... ...
......
...@@ -55,8 +55,8 @@ You can use other versions of Scala and SBT by defining them in ...@@ -55,8 +55,8 @@ You can use other versions of Scala and SBT by defining them in
Add the `Coverage was \[\d+.\d+\%\]` regular expression in the Add the `Coverage was \[\d+.\d+\%\]` regular expression in the
**Settings ➔ Pipelines ➔ Coverage report** project setting to **Settings ➔ Pipelines ➔ Coverage report** project setting to
retrieve the [test coverage] rate from the build trace and have it retrieve the [test coverage](../../user/project/pipelines/settings.md#test-coverage-report-badge)
displayed with your jobs. rate from the build trace and have it displayed with your jobs.
**Pipelines** must be enabled for this option to appear. **Pipelines** must be enabled for this option to appear.
...@@ -69,8 +69,5 @@ in the `.gitlab-ci.yml` file with your application's name. ...@@ -69,8 +69,5 @@ in the `.gitlab-ci.yml` file with your application's name.
## Heroku API key ## Heroku API key
You can look up your Heroku API key in your You can look up your Heroku API key in your
[account](https://dashboard.heroku.com/account). Add a secure [variable] with [account](https://dashboard.heroku.com/account). Add a [protected variable](../variables/README.md#protected-variables) with
this value in **Project ➔ Variables** with key `HEROKU_API_KEY`. this value in **Project ➔ Variables** with key `HEROKU_API_KEY`.
[variable]: ../variables/README.md#user-defined-variables-secure-variables
[test coverage]: ../../user/project/pipelines/settings.md#test-coverage-report-badge
...@@ -4,6 +4,7 @@ author_gitlab: Hostert ...@@ -4,6 +4,7 @@ author_gitlab: Hostert
level: beginner level: beginner
article_type: tutorial article_type: tutorial
date: 2018-02-20 date: 2018-02-20
last_updated: 2019-03-06
--- ---
# Testing a Phoenix application with GitLab CI/CD # Testing a Phoenix application with GitLab CI/CD
...@@ -177,7 +178,7 @@ environment it can run. Since we will work with a single environment, we'll edit ...@@ -177,7 +178,7 @@ environment it can run. Since we will work with a single environment, we'll edit
configuration file (`test.exs`). configuration file (`test.exs`).
But, why do we need to adjust our configuration? Well, GitLab CI/CD builds and tests our code in one But, why do we need to adjust our configuration? Well, GitLab CI/CD builds and tests our code in one
isolated virtual machine, called [Runner][runner-site], using Docker technology. In this Runner, isolated virtual machine, called [Runner](../../runners/README.md), using Docker technology. In this Runner,
GitLab CI/CD has access to everything our Phoenix application need to run, exactly as we have in our GitLab CI/CD has access to everything our Phoenix application need to run, exactly as we have in our
`localhost`, but we have to tell GitLab CI/CD where to create and find this database using system `localhost`, but we have to tell GitLab CI/CD where to create and find this database using system
variables. This way, GitLab CI/CD will create our test database inside the Runner, just like we do variables. This way, GitLab CI/CD will create our test database inside the Runner, just like we do
...@@ -417,7 +418,6 @@ other reasons][ci-reasons] to keep using GitLab CI/CD. The benefits to our teams ...@@ -417,7 +418,6 @@ other reasons][ci-reasons] to keep using GitLab CI/CD. The benefits to our teams
[ci-docs]: ../../README.md "GitLab CI/CD Documentation" [ci-docs]: ../../README.md "GitLab CI/CD Documentation"
[skipping-jobs]: ../../yaml/README.md#skipping-jobs "Skipping Jobs" [skipping-jobs]: ../../yaml/README.md#skipping-jobs "Skipping Jobs"
[gitlab-runners]: ../../runners/README.md "GitLab Runners Documentation" [gitlab-runners]: ../../runners/README.md "GitLab Runners Documentation"
[runner-site]: ../../runners/README.md#runners "Runners"
[docker-image]: https://hub.docker.com/r/trenpixster/elixir/ "Elixir Docker Image" [docker-image]: https://hub.docker.com/r/trenpixster/elixir/ "Elixir Docker Image"
[using-docker]: ../../docker/using_docker_images.md "Using Docker Images" [using-docker]: ../../docker/using_docker_images.md "Using Docker Images"
[hello-gitlab]: https://gitlab.com/Hostert/hello_gitlab_ci "Hello GitLab CI/CD" [hello-gitlab]: https://gitlab.com/Hostert/hello_gitlab_ci "Hello GitLab CI/CD"
This document was moved to [user/permissions.md](../../user/permissions.md#gitlab-ci). ---
redirect_to: '../../user/permissions.md#gitlab-cicd-permissions'
---
This document was moved to [user/permissions.md](../../user/permissions.md#gitlab-cicd-permissions).
...@@ -13,7 +13,7 @@ Review Apps: ...@@ -13,7 +13,7 @@ Review Apps:
- Provide an automatic live preview of changes made in a feature branch by spinning up a dynamic environment for your merge requests. - Provide an automatic live preview of changes made in a feature branch by spinning up a dynamic environment for your merge requests.
- Allow designers and product manages to see your changes without needing to check out your branch and run your changes in a sandbox environment. - Allow designers and product manages to see your changes without needing to check out your branch and run your changes in a sandbox environment.
- Are fully integrated with the [GitLab DevOps LifeCycle](../../README.md#complete-devops-with-gitlab). - Are fully integrated with the [GitLab DevOps LifeCycle](../../README.md#the-entire-devops-lifecycle).
- Allow you to deploy your changes wherever you want. - Allow you to deploy your changes wherever you want.
![Review Apps Workflow](img/continuous-delivery-review-apps.svg) ![Review Apps Workflow](img/continuous-delivery-review-apps.svg)
......
...@@ -10,4 +10,4 @@ be linked with your base image. Below is a list of examples you may use. ...@@ -10,4 +10,4 @@ be linked with your base image. Below is a list of examples you may use.
- [Using MySQL](mysql.md) - [Using MySQL](mysql.md)
- [Using PostgreSQL](postgres.md) - [Using PostgreSQL](postgres.md)
- [Using Redis](redis.md) - [Using Redis](redis.md)
- [Using Other Services](../docker/using_docker_images.md#how-to-use-other-images-as-services) - [Using Other Services](../docker/using_docker_images.md#what-is-a-service)
...@@ -31,7 +31,7 @@ Database: nice_marmot ...@@ -31,7 +31,7 @@ Database: nice_marmot
``` ```
If you are wondering why we used `postgres` for the `Host`, read more at If you are wondering why we used `postgres` for the `Host`, read more at
[How is service linked to the job](../docker/using_docker_images.md#how-is-service-linked-to-the-job). [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][hub-pg].
For example, to use PostgreSQL 9.3 the service becomes `postgres:9.3`. For example, to use PostgreSQL 9.3 the service becomes `postgres:9.3`.
......
...@@ -4,7 +4,7 @@ ...@@ -4,7 +4,7 @@
> >
> - [Introduced](https://about.gitlab.com/2015/08/22/gitlab-7-14-released/) in GitLab 7.14. > - [Introduced](https://about.gitlab.com/2015/08/22/gitlab-7-14-released/) in GitLab 7.14.
> - GitLab 8.12 has a completely redesigned job permissions system. Read all > - GitLab 8.12 has a completely redesigned job permissions system. Read all
> about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers). > about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#pipeline-triggers).
Triggers can be used to force a pipeline rerun of a specific `ref` (branch or Triggers can be used to force a pipeline rerun of a specific `ref` (branch or
tag) with an API call. tag) with an API call.
...@@ -219,7 +219,7 @@ Old triggers, created before GitLab 9.0 will be marked as legacy. ...@@ -219,7 +219,7 @@ 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 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 access to the current project. They are considered deprecated and will be
removed with one of the future versions of GitLab. You are advised to removed with one of the future versions of GitLab. You are advised to
[take ownership](#taking-ownership) of any legacy triggers. [take ownership](#taking-ownership-of-a-trigger) of any legacy triggers.
[ee-2017]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2017 [ee-2017]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2017
[ee]: https://about.gitlab.com/pricing/ [ee]: https://about.gitlab.com/pricing/
......
...@@ -16,7 +16,7 @@ Variables of different types can take precedence over other variables, depending ...@@ -16,7 +16,7 @@ Variables of different types can take precedence over other variables, depending
The order of precedence for variables is (from highest to lowest): The order of precedence for variables is (from highest to lowest):
1. [Trigger variables](../triggers/README.md#pass-job-variables-to-a-trigger) or [scheduled pipeline variables](../../user/project/pipelines/schedules.md#making-use-of-scheduled-pipeline-variables). 1. [Trigger variables](../triggers/README.md#making-use-of-trigger-variables) or [scheduled pipeline variables](../../user/project/pipelines/schedules.md#making-use-of-scheduled-pipeline-variables).
1. Project-level [variables](#variables) or [protected variables](#protected-variables). 1. Project-level [variables](#variables) or [protected variables](#protected-variables).
1. Group-level [variables](#variables) or [protected variables](#protected-variables). 1. Group-level [variables](#variables) or [protected variables](#protected-variables).
1. YAML-defined [job-level variables](../yaml/README.md#variables). 1. YAML-defined [job-level variables](../yaml/README.md#variables).
...@@ -46,7 +46,7 @@ version of Runner required. ...@@ -46,7 +46,7 @@ version of Runner required.
NOTE: **Note:** NOTE: **Note:**
Starting with GitLab 9.0, we have deprecated some variables. Read the Starting with GitLab 9.0, we have deprecated some variables. Read the
[9.0 Renaming](#9-0-renaming) section to find out their replacements. **You are [9.0 Renaming](#gitlab-90-renaming) section to find out their replacements. **You are
strongly advised to use the new variables as we will remove the old ones in strongly advised to use the new variables as we will remove the old ones in
future GitLab releases.** future GitLab releases.**
...@@ -311,7 +311,7 @@ variables that were set, etc. ...@@ -311,7 +311,7 @@ variables that were set, etc.
Before enabling this, you should ensure jobs are visible to Before enabling this, you should ensure jobs are visible to
[team members only](../../user/permissions.md#project-features). You should [team members only](../../user/permissions.md#project-features). You should
also [erase](../pipelines.md#seeing-build-status) all generated job traces also [erase](../pipelines.md#seeing-job-status) all generated job traces
before making them visible again. before making them visible again.
To enable debug traces, set the `CI_DEBUG_TRACE` variable to `true`: To enable debug traces, set the `CI_DEBUG_TRACE` variable to `true`:
......
...@@ -106,9 +106,9 @@ The following variables are known as "persisted": ...@@ -106,9 +106,9 @@ The following variables are known as "persisted":
They are: They are:
- Supported for definitions where the ["Expansion place"](#gitlab-ci-yml-file) is: - Supported for definitions where the ["Expansion place"](#gitlab-ciyml-file) is:
- Runner. - Runner.
- Script execution shell. - Script execution shell.
- Not supported: - Not supported:
- For definitions where the ["Expansion place"](#gitlab-ci-yml-file) is GitLab. - For definitions where the ["Expansion place"](#gitlab-ciyml-file) is GitLab.
- In the `only` and `except` [variables expressions](README.md#variables-expressions). - In the `only` and `except` [variables expressions](README.md#variables-expressions).
...@@ -26,7 +26,7 @@ If you want to disable it for a specific project, you can do so in ...@@ -26,7 +26,7 @@ If you want to disable it for a specific project, you can do so in
The maximum size of the [job artifacts][art-yml] can be set in the Admin area The maximum size of the [job artifacts][art-yml] can be set in the Admin area
of your GitLab instance. The value is in *MB* and the default is 100MB per job; of your GitLab instance. The value is in *MB* and the default is 100MB per job;
on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-ci-cd). on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-cicd).
To change it: To change it:
...@@ -40,7 +40,7 @@ The default expiration time of the [job artifacts](../../../administration/job_a ...@@ -40,7 +40,7 @@ The default expiration time of the [job artifacts](../../../administration/job_a
can be set in the Admin area of your GitLab instance. The syntax of duration is can be set in the Admin area of your GitLab instance. The syntax of duration is
described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in)
and the default value is `30 days`. On GitLab.com they and the default value is `30 days`. On GitLab.com they
[never expire](../../gitlab_com/index.md#gitlab-ci-cd). [never expire](../../gitlab_com/index.md#gitlab-cicd).
1. Go to **Admin area > Settings > Continuous Integration and Deployment**. 1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
1. Change the value of default expiration time. 1. Change the value of default expiration time.
......
...@@ -51,7 +51,7 @@ Below are the settings for [GitLab Pages]. ...@@ -51,7 +51,7 @@ Below are the settings for [GitLab Pages].
| TLS certificates support| yes | no | | TLS certificates support| yes | no |
The maximum size of your Pages site is regulated by the artifacts maximum size The maximum size of your Pages site is regulated by the artifacts maximum size
which is part of [GitLab CI/CD](#gitlab-ci-cd). which is part of [GitLab CI/CD](#gitlab-cicd).
## GitLab CI/CD ## GitLab CI/CD
......
...@@ -72,11 +72,10 @@ The domain should have a wildcard DNS configured to the Ingress IP address. ...@@ -72,11 +72,10 @@ The domain should have a wildcard DNS configured to the Ingress IP address.
## Environment scopes **[PREMIUM]** ## Environment scopes **[PREMIUM]**
When adding more than one Kubernetes cluster to your project, you need When adding more than one Kubernetes cluster to your project, you need to differentiate
to differentiate them with an environment scope. The environment scope them with an environment scope. The environment scope associates clusters with
associates clusters with [environments](../../../ci/environments.md) [environments](../../../ci/environments.md) similar to how the
similar to how the [environment-specific [environment-specific variables](https://docs.gitlab.com/ee/ci/variables/README.html#limiting-environment-scopes-of-variables-premium)
variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables)
work. work.
While evaluating which environment matches the environment scope of a While evaluating which environment matches the environment scope of a
......
...@@ -477,12 +477,9 @@ differentiate the new cluster with the rest. ...@@ -477,12 +477,9 @@ differentiate the new cluster with the rest.
## Setting the environment scope **[PREMIUM]** ## Setting the environment scope **[PREMIUM]**
When adding more than one Kubernetes clusters to your project, you need When adding more than one Kubernetes cluster to your project, you need to differentiate
to differentiate them with an environment scope. The environment scope them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments.md) similar to how the
associates clusters with [environments](../../../ci/environments.md) [environment-specific variables](https://docs.gitlab.com/ee/ci/variables/README.html#limiting-environment-scopes-of-variables-premium) work.
similar to how the [environment-specific
variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables)
work.
The default environment scope is `*`, which means all jobs, regardless of their The default environment scope is `*`, which means all jobs, regardless of their
environment, will use that cluster. Each scope can only be used by a single environment, will use that cluster. Each scope can only be used by a single
...@@ -545,7 +542,7 @@ GitLab CI/CD build environment. ...@@ -545,7 +542,7 @@ GitLab CI/CD build environment.
| `KUBE_CA_PEM_FILE` | Path to a file containing PEM data. Only present if a custom CA bundle was specified. | | `KUBE_CA_PEM_FILE` | Path to a file containing PEM data. Only present if a custom CA bundle was specified. |
| `KUBE_CA_PEM` | (**deprecated**) Raw PEM data. Only if a custom CA bundle was specified. | | `KUBE_CA_PEM` | (**deprecated**) Raw PEM data. Only if a custom CA bundle was specified. |
| `KUBECONFIG` | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This config also embeds the same token defined in `KUBE_TOKEN` so you likely will only need this variable. This variable name is also automatically picked up by `kubectl` so you won't actually need to reference it explicitly if using `kubectl`. | | `KUBECONFIG` | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This config also embeds the same token defined in `KUBE_TOKEN` so you likely will only need this variable. This variable name is also automatically picked up by `kubectl` so you won't actually need to reference it explicitly if using `kubectl`. |
| `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, this variable can be used to set a domain per cluster. See [cluster domains](#base-domain) for more information. |  | `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, this variable can be used to set a domain per cluster. See [cluster domains](#base-domain) for more information. |
NOTE: **NOTE:** NOTE: **NOTE:**
Prior to GitLab 11.5, `KUBE_TOKEN` was the Kubernetes token of the main Prior to GitLab 11.5, `KUBE_TOKEN` was the Kubernetes token of the main
......
...@@ -13,7 +13,7 @@ There are two ways to set up Prometheus integration, depending on where your app ...@@ -13,7 +13,7 @@ There are two ways to set up Prometheus integration, depending on where your app
- For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes). - For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes).
- For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus). - For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus).
Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-ci-cd-environments). Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-cicd-environments).
## Enabling Prometheus Integration ## Enabling Prometheus Integration
......
...@@ -49,7 +49,7 @@ It is important to note that we have a few types of users: ...@@ -49,7 +49,7 @@ It is important to note that we have a few types of users:
Administrator will have to be a member of it in order to have access to it Administrator will have to be a member of it in order to have access to it
via another project's job. via another project's job.
- **External users**: CI jobs created by [external users][ext] will have - **External users**: CI jobs created by [external users](../permissions.md#external-users-permissions) will have
access only to projects to which user has at least reporter access. This access only to projects to which user has at least reporter access. This
rules out accessing all internal projects by default, rules out accessing all internal projects by default,
...@@ -60,7 +60,7 @@ Let's consider the following scenario: ...@@ -60,7 +60,7 @@ Let's consider the following scenario:
hosted in private repositories and you have multiple CI jobs that make use hosted in private repositories and you have multiple CI jobs that make use
of these repositories. of these repositories.
1. You invite a new [external user][ext]. CI jobs created by that user do not 1. You invite a new [external user](../permissions.md#external-users-permissions). CI jobs created by that user do not
have access to internal repositories, because the user also doesn't have the have access to internal repositories, because the user also doesn't have the
access from within GitLab. You as an employee have to grant explicit access access from within GitLab. You as an employee have to grant explicit access
for this user. This allows us to prevent from accidental data leakage. for this user. This allows us to prevent from accidental data leakage.
...@@ -232,7 +232,6 @@ test: ...@@ -232,7 +232,6 @@ test:
[job permissions]: ../permissions.md#job-permissions [job permissions]: ../permissions.md#job-permissions
[comment]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22484#note_16648302 [comment]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22484#note_16648302
[ext]: ../permissions.md#external-users
[gitsub]: ../../ci/git_submodules.md [gitsub]: ../../ci/git_submodules.md
[https]: ../admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols [https]: ../admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols
[triggers]: ../../ci/triggers/README.md [triggers]: ../../ci/triggers/README.md
......
...@@ -115,7 +115,7 @@ gives you absolute control over the build process. You can actually watch your ...@@ -115,7 +115,7 @@ gives you absolute control over the build process. You can actually watch your
website being built live by following the CI job traces. website being built live by following the CI job traces.
For a simplified user guide on setting up GitLab CI/CD for Pages, read through For a simplified user guide on setting up GitLab CI/CD for Pages, read through
the article [GitLab Pages from A to Z: Part 4 - Creating and Tweaking `.gitlab-ci.yml` for GitLab Pages](getting_started_part_four.md#creating-and-tweaking-gitlab-ci-yml-for-gitlab-pages) the article [GitLab Pages from A to Z: Part 4 - Creating and Tweaking `.gitlab-ci.yml` for GitLab Pages](getting_started_part_four.md)
> **Note:** > **Note:**
> Before reading this section, make sure you familiarize yourself with GitLab CI > Before reading this section, make sure you familiarize yourself with GitLab CI
......
...@@ -183,7 +183,7 @@ information in the UI. ...@@ -183,7 +183,7 @@ information in the UI.
DANGER: **Warning:** DANGER: **Warning:**
This is a destructive action that leads to data loss. Use with caution. This is a destructive action that leads to data loss. Use with caution.
If you have at least Developer [permissions](../../permissions.md#gitlab-ci-cd-permissions) If you have at least Developer [permissions](../../permissions.md#gitlab-cicd-permissions)
on the project, you can erase a single job via the UI which will also remove the on the project, you can erase a single job via the UI which will also remove the
artifacts and the job's trace. artifacts and the job's trace.
......
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