Docs: Fix CI/CD related anchors
This commit is contained in:
Marcel Amirault
Evan Read
parent
f2a53ee44d
commit
8272b0c8bd
20 changed files with 42 additions and 44 deletions
|
|
@ -48,7 +48,7 @@ into more features:
|
|||
| [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. |
|
||||
| [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/). |
|
||||
| [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. |
|
||||
|
|
|
|||
|
|
@ -4,6 +4,7 @@ author_gitlab: blitzgren
|
|||
level: intermediate
|
||||
article_type: tutorial
|
||||
date: 2018-03-07
|
||||
last_updated: 2019-03-06
|
||||
---
|
||||
|
||||
# DevOps and Game Dev with GitLab CI/CD
|
||||
|
|
@ -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:
|
||||
|
||||
- [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
|
||||
- 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/)
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ author_gitlab: mehranrasulian
|
|||
level: intermediate
|
||||
article_type: tutorial
|
||||
date: 2017-08-31
|
||||
last_updated: 2019-03-06
|
||||
---
|
||||
|
||||
# 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.
|
|||
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.
|
||||
|
||||
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.
|
||||
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
|
|||
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.
|
||||
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
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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
|
||||
**Settings ➔ Pipelines ➔ Coverage report** project setting to
|
||||
retrieve the [test coverage] rate from the build trace and have it
|
||||
displayed with your jobs.
|
||||
retrieve the [test coverage](../../user/project/pipelines/settings.md#test-coverage-report-badge)
|
||||
rate from the build trace and have it displayed with your jobs.
|
||||
|
||||
**Pipelines** must be enabled for this option to appear.
|
||||
|
||||
|
|
@ -69,8 +69,5 @@ in the `.gitlab-ci.yml` file with your application's name.
|
|||
## Heroku API key
|
||||
|
||||
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`.
|
||||
|
||||
[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
|
|||
level: beginner
|
||||
article_type: tutorial
|
||||
date: 2018-02-20
|
||||
last_updated: 2019-03-06
|
||||
---
|
||||
|
||||
# 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
|
|||
configuration file (`test.exs`).
|
||||
|
||||
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
|
||||
`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
|
||||
|
|
@ -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"
|
||||
[skipping-jobs]: ../../yaml/README.md#skipping-jobs "Skipping Jobs"
|
||||
[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"
|
||||
[using-docker]: ../../docker/using_docker_images.md "Using Docker Images"
|
||||
[hello-gitlab]: https://gitlab.com/Hostert/hello_gitlab_ci "Hello GitLab CI/CD"
|
||||
|
|
|
|||
|
|
@ -1 +1,5 @@
|
|||
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:
|
|||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,4 +10,4 @@ be linked with your base image. Below is a list of examples you may use.
|
|||
- [Using MySQL](mysql.md)
|
||||
- [Using PostgreSQL](postgres.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
|
|||
```
|
||||
|
||||
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].
|
||||
For example, to use PostgreSQL 9.3 the service becomes `postgres:9.3`.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
>
|
||||
> - [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
|
||||
> 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
|
||||
tag) with an API call.
|
||||
|
|
@ -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
|
||||
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
|
||||
[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]: https://about.gitlab.com/pricing/
|
||||
|
|
|
|||
|
|
@ -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):
|
||||
|
||||
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. Group-level [variables](#variables) or [protected variables](#protected-variables).
|
||||
1. YAML-defined [job-level variables](../yaml/README.md#variables).
|
||||
|
|
@ -46,7 +46,7 @@ version of Runner required.
|
|||
|
||||
NOTE: **Note:**
|
||||
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
|
||||
future GitLab releases.**
|
||||
|
||||
|
|
@ -311,7 +311,7 @@ variables that were set, etc.
|
|||
|
||||
Before enabling this, you should ensure jobs are visible to
|
||||
[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.
|
||||
|
||||
To enable debug traces, set the `CI_DEBUG_TRACE` variable to `true`:
|
||||
|
|
|
|||
|
|
@ -106,9 +106,9 @@ The following variables are known as "persisted":
|
|||
|
||||
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.
|
||||
- Script execution shell.
|
||||
- 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).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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:
|
||||
|
||||
|
|
@ -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
|
||||
described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in)
|
||||
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. Change the value of default expiration time.
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ Below are the settings for [GitLab Pages].
|
|||
| TLS certificates support| yes | no |
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -72,11 +72,10 @@ The domain should have a wildcard DNS configured to the Ingress IP address.
|
|||
|
||||
## Environment scopes **[PREMIUM]**
|
||||
|
||||
When adding more than one Kubernetes cluster to your project, you need
|
||||
to differentiate them with an environment scope. The environment scope
|
||||
associates clusters with [environments](../../../ci/environments.md)
|
||||
similar to how the [environment-specific
|
||||
variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables)
|
||||
When adding more than one Kubernetes cluster to your project, you need to differentiate
|
||||
them with an environment scope. The environment scope associates clusters with
|
||||
[environments](../../../ci/environments.md) similar to how the
|
||||
[environment-specific variables](https://docs.gitlab.com/ee/ci/variables/README.html#limiting-environment-scopes-of-variables-premium)
|
||||
work.
|
||||
|
||||
While evaluating which environment matches the environment scope of a
|
||||
|
|
|
|||
|
|
@ -477,12 +477,9 @@ differentiate the new cluster with the rest.
|
|||
|
||||
## Setting the environment scope **[PREMIUM]**
|
||||
|
||||
When adding more than one Kubernetes clusters to your project, you need
|
||||
to differentiate them with an environment scope. The environment scope
|
||||
associates clusters with [environments](../../../ci/environments.md)
|
||||
similar to how the [environment-specific
|
||||
variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables)
|
||||
work.
|
||||
When adding more than one Kubernetes cluster to your project, you need to differentiate
|
||||
them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments.md) similar to how the
|
||||
[environment-specific variables](https://docs.gitlab.com/ee/ci/variables/README.html#limiting-environment-scopes-of-variables-premium) work.
|
||||
|
||||
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
|
||||
|
|
@ -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` | (**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`. |
|
||||
| `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:**
|
||||
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
|
|||
- 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).
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
rules out accessing all internal projects by default,
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ Let's consider the following scenario:
|
|||
hosted in private repositories and you have multiple CI jobs that make use
|
||||
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
|
||||
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.
|
||||
|
|
@ -232,7 +232,6 @@ test:
|
|||
|
||||
[job permissions]: ../permissions.md#job-permissions
|
||||
[comment]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22484#note_16648302
|
||||
[ext]: ../permissions.md#external-users
|
||||
[gitsub]: ../../ci/git_submodules.md
|
||||
[https]: ../admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols
|
||||
[triggers]: ../../ci/triggers/README.md
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
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:**
|
||||
> Before reading this section, make sure you familiarize yourself with GitLab CI
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ information in the UI.
|
|||
DANGER: **Warning:**
|
||||
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
|
||||
artifacts and the job's trace.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue