@@ -11,7 +11,7 @@ A cache is one or more files that a job downloads and saves. Subsequent jobs tha
the same cache don't have to download the files again, so they execute more quickly.
To learn how to define the cache in your `.gitlab-ci.yml` file,
see the [`cache` reference](../yaml/README.md#cache).
see the [`cache` reference](../yaml/index.md#cache).
## How cache is different from artifacts
...
...
@@ -38,8 +38,8 @@ can't link to files outside it.
- Subsequent jobs in later stages of the same pipeline can use artifacts.
- Different projects cannot share artifacts.
Artifacts expire after 30 days unless you define an [expiration time](../yaml/README.md#artifactsexpire_in).
Use [dependencies](../yaml/README.md#dependencies) to control which jobs fetch the artifacts.
Artifacts expire after 30 days unless you define an [expiration time](../yaml/index.md#artifactsexpire_in).
Use [dependencies](../yaml/index.md#dependencies) to control which jobs fetch the artifacts.
## Good caching practices
...
...
@@ -48,7 +48,7 @@ To ensure maximum availability of the cache, do one or more of the following:
-[Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
that share the cache.
-[Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
-[Use a `key`](../yaml/README.md#cachekey) that fits your workflow. For example,
-[Use a `key`](../yaml/index.md#cachekey) that fits your workflow. For example,
you can configure a different cache for each branch.
For runners to work with caches efficiently, you must do one of the following:
...
...
@@ -97,7 +97,7 @@ the fallback cache is fetched every time a cache is not found.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) in GitLab Runner 13.4.
You can use the `$CI_COMMIT_REF_SLUG`[predefined variable](../variables/predefined_variables.md)
to specify your [`cache:key`](../yaml/README.md#cachekey). For example, if your
to specify your [`cache:key`](../yaml/index.md#cachekey). For example, if your
`$CI_COMMIT_REF_SLUG` is `test`, you can set a job to download cache that's tagged with `test`.
If a cache with this tag is not found, you can use `CACHE_FALLBACK_KEY` to
...
...
@@ -134,7 +134,7 @@ job:
## Inherit global configuration, but override specific settings per job
You can override cache settings without overwriting the global cache by using
[anchors](../yaml/README.md#anchors). For example, if you want to override the
[anchors](../yaml/index.md#anchors). For example, if you want to override the
`policy` for one job:
```yaml
...
...
@@ -154,7 +154,7 @@ job:
policy:pull
```
For more information, see [`cache: policy`](../yaml/README.md#cachepolicy).
For more information, see [`cache: policy`](../yaml/index.md#cachepolicy).
## Common use cases for caches
...
...
@@ -212,7 +212,7 @@ cache:
If your project uses [npm](https://www.npmjs.com/) to install Node.js
dependencies, the following example defines `cache` globally so that all jobs inherit it.
By default, npm stores cache data in the home folder (`~/.npm`). However, you
[can't cache things outside of the project directory](../yaml/README.md#cachepaths).
[can't cache things outside of the project directory](../yaml/index.md#cachepaths).
Instead, tell npm to use `./.npm`, and cache it per-branch:
```yaml
...
...
@@ -392,7 +392,7 @@ test:
Caching is an optimization, but it isn't guaranteed to always work. You might need
to regenerate cached files in each job that needs them.
After you define a [cache in `.gitlab-ci.yml`](../yaml/README.md#cache),
After you define a [cache in `.gitlab-ci.yml`](../yaml/index.md#cache),
the availability of the cache depends on:
- The runner's executor type.
...
...
@@ -489,7 +489,7 @@ machines, it is a safe default.
## Clearing the cache
Runners use [cache](../yaml/README.md#cache) to speed up the execution
Runners use [cache](../yaml/index.md#cache) to speed up the execution
of your jobs by reusing existing data. This can sometimes lead to
@@ -91,7 +91,7 @@ path to point to your ECR image.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207962) in GitLab 12.9.
> - The `Deploy-ECS.gitlab-ci.yml` template was [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/220821) to `AWS/Deploy-ECS.gitlab-ci.yml` in GitLab 13.2.
GitLab provides a series of [CI templates that you can include in your project](../yaml/README.md#include).
GitLab provides a series of [CI templates that you can include in your project](../yaml/index.md#include).
To automate deployments of your application to your [Amazon Elastic Container Service](https://aws.amazon.com/ecs/)(AWS ECS)
cluster, you can `include` the `AWS/Deploy-ECS.gitlab-ci.yml` template in your `.gitlab-ci.yml` file.
...
...
@@ -231,7 +231,7 @@ pass three JSON input objects, based on existing templates:
-[Template for the _Create stack_ step on AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html).
- Template for the _Push to S3_ step. Note that `source` is where a preceding `build` job built
your application, exporting the build through [`artifacts:paths`](../yaml/README.md#artifactspaths):
your application, exporting the build through [`artifacts:paths`](../yaml/index.md#artifactspaths):
@@ -146,10 +146,10 @@ new browser window interacting with your app as you specified.
Which brings us to the exciting part: how do we run this in GitLab CI/CD? There are two things we
need to do for this:
1. Set up [CI/CD jobs](../../yaml/README.md) that actually have a browser available.
1. Set up [CI/CD jobs](../../yaml/index.md) that actually have a browser available.
1. Update our WebdriverIO configuration to use those browsers to visit the review apps.
For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages)
For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/index.md#stages)
`confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest`[Docker
image](../../docker/using_docker_images.md). However, WebdriverIO fires up actual browsers
to interact with your application, so we need to install and run them.
...
...
@@ -255,5 +255,5 @@ production project, see:
There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](http://v4.webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take
a screenshot when tests are failing. Then tell GitLab CI/CD to store those
[artifacts](../../yaml/README.md#artifacts), and you'll be able to see what went
[artifacts](../../yaml/index.md#artifacts), and you'll be able to see what went
@@ -548,7 +548,7 @@ If you wish to test your app with different PHP versions and [database managemen
#### CI/CD variables
GitLab CI/CD allows us to use [CI/CD variables](../../yaml/README.md#variables) in our jobs.
GitLab CI/CD allows us to use [CI/CD variables](../../yaml/index.md#variables) in our jobs.
We defined MySQL as our database management system, which comes with a superuser root created by default.
So we should adjust the configuration of MySQL instance by defining `MYSQL_DATABASE` variable as our database name and `MYSQL_ROOT_PASSWORD` variable as the password of `root`.
...
...
@@ -567,7 +567,7 @@ variables:
#### Unit Test as the first job
We defined the required shell scripts as an array of the [script](../../yaml/README.md#script) keyword to be executed when running `unit_test` job.
We defined the required shell scripts as an array of the [script](../../yaml/index.md#script) keyword to be executed when running `unit_test` job.
These scripts are some Artisan commands to prepare the Laravel, and, at the end of the script, we'll run the tests by `PHPUnit`.
...
...
@@ -593,7 +593,7 @@ To deploy our app with Envoy, we had to set up the `$SSH_PRIVATE_KEY` variable a
If the SSH keys have added successfully, we can run Envoy.
As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well.
The [environment](../../yaml/README.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
The [environment](../../yaml/index.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
The `url` keyword is used to generate a link to our application on the GitLab Environments page.
The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `main` branch.
Lastly, `when: manual` is used to turn the job from running automatically to a manual action.
| [Pipelines for Merge Requests](merge_request_pipelines/index.md) | Design a pipeline structure for running a pipeline in merge requests. |
| [Integrate with Kubernetes clusters](../user/project/clusters/index.md) | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
| [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. |
| [`.gitlab-ci.yml` full reference](yaml/README.md) | All the attributes you can use with GitLab CI/CD. |
| [`.gitlab-ci.yml` full reference](yaml/index.md) | All the attributes you can use with GitLab CI/CD. |
Note that certain operations can only be performed according to the
[user](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions.
