Docs: Fix all anchors related to YAML
This commit is contained in:
parent
a6d52ff83f
commit
4672501864
10 changed files with 21 additions and 21 deletions
|
@ -52,7 +52,7 @@ artifacts are also available in between stages within a pipeline. So if you
|
|||
build your application by downloading all the required modules, you might want
|
||||
to declare them as artifacts so that each subsequent stage can depend on them
|
||||
being there. There are some optimizations like declaring an
|
||||
[expiry time](../yaml/README.md#artifacts-expire_in) so you don't keep artifacts
|
||||
[expiry time](../yaml/README.md#artifactsexpire_in) so you don't keep artifacts
|
||||
around too long, and using [dependencies](../yaml/README.md#dependencies) to
|
||||
control exactly where artifacts are passed around.
|
||||
|
||||
|
@ -87,7 +87,7 @@ cache, when declaring `cache` in your jobs, use one or a mix of the following:
|
|||
that share their cache.
|
||||
- [Use sticky Runners](../runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)
|
||||
that will be only available to a particular project.
|
||||
- [Use a `key`](../yaml/README.md#cache-key) that fits your workflow (e.g.,
|
||||
- [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (e.g.,
|
||||
different caches on each branch). For that, you can take advantage of the
|
||||
[CI/CD predefined variables](../variables/README.md#predefined-environment-variables).
|
||||
|
||||
|
@ -169,7 +169,7 @@ job:
|
|||
```
|
||||
|
||||
For more fine tuning, read also about the
|
||||
[`cache: policy`](../yaml/README.md#cache-policy).
|
||||
[`cache: policy`](../yaml/README.md#cachepolicy).
|
||||
|
||||
## Common use cases
|
||||
|
||||
|
|
|
@ -391,9 +391,9 @@ CI jobs:
|
|||
from `Dockerfile` that may be overridden in `.gitlab-ci.yml`)
|
||||
1. The Runner attaches itself to a running container.
|
||||
1. The Runner prepares a script (the combination of
|
||||
[`before_script`](../yaml/README.md#before_script),
|
||||
[`before_script`](../yaml/README.md#before_script-and-after_script),
|
||||
[`script`](../yaml/README.md#script),
|
||||
and [`after_script`](../yaml/README.md#after_script)).
|
||||
and [`after_script`](../yaml/README.md#before_script-and-after_script)).
|
||||
1. The Runner sends the script to the container's shell STDIN and receives the
|
||||
output.
|
||||
|
||||
|
|
|
@ -103,7 +103,7 @@ the Git SHA and environment name.
|
|||
To sum up, with the above `.gitlab-ci.yml` we have achieved that:
|
||||
|
||||
- All branches will run the `test` and `build` jobs.
|
||||
- The `deploy_staging` job will run [only](yaml/README.md#only) on the `master`
|
||||
- The `deploy_staging` job will run [only](yaml/README.md#only-and-except-simplified) on the `master`
|
||||
branch which means all merge requests that are created from branches don't
|
||||
get to deploy to the staging server
|
||||
- When a merge request is merged, all jobs will run and the `deploy_staging`
|
||||
|
@ -401,7 +401,7 @@ Let's briefly see where URL that's defined in the environments is exposed.
|
|||
|
||||
## Making use of the environment URL
|
||||
|
||||
The [environment URL](yaml/README.md#environments-url) is exposed in a few
|
||||
The [environment URL](yaml/README.md#environmenturl) is exposed in a few
|
||||
places within GitLab.
|
||||
|
||||
| In a merge request widget as a link | In the Environments view as a button | In the Deployments view as a button |
|
||||
|
@ -619,9 +619,9 @@ Below are some links you may find interesting:
|
|||
[deployments]: #deployments
|
||||
[permissions]: ../user/permissions.md
|
||||
[variables]: variables/README.md
|
||||
[env-name]: yaml/README.md#environment-name
|
||||
[only]: yaml/README.md#only-and-except
|
||||
[onstop]: yaml/README.md#environment-on_stop
|
||||
[env-name]: yaml/README.md#environmentname
|
||||
[only]: yaml/README.md#only-and-except-simplified
|
||||
[onstop]: yaml/README.md#environmenton_stop
|
||||
[ce-7015]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7015
|
||||
[gitlab-flow]: ../workflow/gitlab_flow.md
|
||||
[gitlab runner]: https://docs.gitlab.com/runner/
|
||||
|
|
|
@ -197,7 +197,7 @@ stage has a job with a manual action.
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21767) in GitLab 11.4.
|
||||
|
||||
When you do not want to run a job immediately, you can [delay the job to run after a certain period](yaml/README.md#when-delayed).
|
||||
When you do not want to run a job immediately, you can [delay the job to run after a certain period](yaml/README.md#whendelayed).
|
||||
This is especially useful for timed incremental rollout that new code is rolled out gradually.
|
||||
For example, if you start rolling out new code and users do not experience trouble, GitLab automatically completes the deployment from 0% to 100%.
|
||||
Alternatively, if you start rolling out and you noticed that a few users experience trouble with the version,
|
||||
|
|
|
@ -92,7 +92,7 @@ to access it. This is where an SSH key pair comes in handy.
|
|||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
The [`before_script`](../yaml/README.md#before-script) can be set globally
|
||||
The [`before_script`](../yaml/README.md#before_script-and-after_script) can be set globally
|
||||
or per-job.
|
||||
|
||||
1. Make sure the private server's [SSH host keys are verified](#verifying-the-ssh-host-keys).
|
||||
|
|
|
@ -1206,7 +1206,7 @@ job:
|
|||
`expire_in` allows you to specify how long artifacts should live before they
|
||||
expire and therefore deleted, counting from the time they are uploaded and
|
||||
stored on GitLab. If the expiry time is not defined, it defaults to the
|
||||
[instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration)
|
||||
[instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only)
|
||||
(30 days by default, forever on GitLab.com).
|
||||
|
||||
You can use the **Keep** button on the job page to override expiration and
|
||||
|
@ -1245,7 +1245,7 @@ this with [JUnit reports](#artifactsreportsjunit).
|
|||
|
||||
NOTE: **Note:**
|
||||
The test reports are collected regardless of the job results (success or failure).
|
||||
You can use [`artifacts:expire_in`](#artifacts-expire_in) to set up an expiration
|
||||
You can use [`artifacts:expire_in`](#artifactsexpire_in) to set up an expiration
|
||||
date for their artifacts.
|
||||
|
||||
NOTE: **Note:**
|
||||
|
@ -1425,7 +1425,7 @@ deploy:
|
|||
> Introduced in GitLab 10.3.
|
||||
|
||||
If the artifacts of the job that is set as a dependency have been
|
||||
[expired](#artifacts-expire_in) or
|
||||
[expired](#artifactsexpire_in) or
|
||||
[erased](../../user/project/pipelines/job_artifacts.md#erasing-artifacts), then
|
||||
the dependent job will fail.
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ To change it:
|
|||
|
||||
The default expiration time of the [job artifacts](../../../administration/job_artifacts.md)
|
||||
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#artifacts-expire_in)
|
||||
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).
|
||||
|
||||
|
@ -47,7 +47,7 @@ and the default value is `30 days`. On GitLab.com they
|
|||
1. Hit **Save changes** for the changes to take effect.
|
||||
|
||||
This setting is set per job and can be overridden in
|
||||
[`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifacts-expire_in).
|
||||
[`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifactsexpire_in).
|
||||
To disable the expiration, set it to `0`. The default unit is in seconds.
|
||||
|
||||
## Archive jobs **[CORE ONLY]**
|
||||
|
|
|
@ -60,7 +60,7 @@ Below are the current settings regarding [GitLab CI/CD](../../ci/README.md).
|
|||
| Setting | GitLab.com | Default |
|
||||
| ----------- | ----------------- | ------------- |
|
||||
| Artifacts maximum size | 1G | 100M |
|
||||
| Artifacts [expiry time](../../ci/yaml/README.md#artifacts-expire_in) | kept forever | deleted after 30 days unless otherwise specified |
|
||||
| Artifacts [expiry time](../../ci/yaml/README.md#artifactsexpire_in) | kept forever | deleted after 30 days unless otherwise specified |
|
||||
|
||||
## Repository size limit
|
||||
|
||||
|
|
|
@ -151,7 +151,7 @@ Depending on how you plan to publish your website, the steps defined in the
|
|||
|
||||
Be aware that Pages are by default branch/tag agnostic and their deployment
|
||||
relies solely on what you specify in `.gitlab-ci.yml`. If you don't limit the
|
||||
`pages` job with the [`only` parameter](../../../ci/yaml/README.md#only-and-except),
|
||||
`pages` job with the [`only` parameter](../../../ci/yaml/README.md#only-and-except-simplified),
|
||||
whenever a new commit is pushed to whatever branch or tag, the Pages will be
|
||||
overwritten. In the example below, we limit the Pages to be deployed whenever
|
||||
a commit is pushed only on the `master` branch:
|
||||
|
@ -252,7 +252,7 @@ get you started.
|
|||
|
||||
Remember that GitLab Pages are by default branch/tag agnostic and their
|
||||
deployment relies solely on what you specify in `.gitlab-ci.yml`. You can limit
|
||||
the `pages` job with the [`only` parameter](../../../ci/yaml/README.md#only-and-except),
|
||||
the `pages` job with the [`only` parameter](../../../ci/yaml/README.md#only-and-except-simplified),
|
||||
whenever a new commit is pushed to a branch that will be used specifically for
|
||||
your pages.
|
||||
|
||||
|
|
|
@ -195,5 +195,5 @@ artifacts and the job's trace.
|
|||
|
||||
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]: ../../../ci/yaml/README.md#artifacts-expire_in
|
||||
[expiry date]: ../../../ci/yaml/README.md#artifactsexpire_in
|
||||
[ce-14399]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14399
|
Loading…
Reference in a new issue