Docs: Fix missed or newly added broken anchors
This commit is contained in:
parent
6c36fe9d29
commit
b41b03d47c
|
@ -475,7 +475,7 @@ GET /projects/:id/repository/commits/:sha/statuses
|
|||
| `sha` | string | yes | The commit SHA
|
||||
| `ref` | string | no | The name of a repository branch or tag or, if not given, the default branch
|
||||
| `stage` | string | no | Filter by [build stage](../ci/yaml/README.md#stages), e.g., `test`
|
||||
| `name` | string | no | Filter by [job name](../ci/yaml/README.md#jobs), e.g., `bundler:audit`
|
||||
| `name` | string | no | Filter by [job name](../ci/yaml/README.md#introduction), e.g., `bundler:audit`
|
||||
| `all` | boolean | no | Return all statuses, not only the latest ones
|
||||
|
||||
```bash
|
||||
|
|
|
@ -15,7 +15,7 @@ GET /projects/:id/releases/:tag_name/assets/links
|
|||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------- | -------------- | -------- | --------------------------------------- |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
|
||||
| `tag_name` | string | yes | The tag associated with the Release. |
|
||||
|
||||
Example request:
|
||||
|
@ -53,7 +53,7 @@ GET /projects/:id/releases/:tag_name/assets/links/:link_id
|
|||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------- | -------------- | -------- | --------------------------------------- |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
|
||||
| `tag_name` | string | yes | The tag associated with the Release. |
|
||||
| `link_id` | integer | yes | The id of the link. |
|
||||
|
||||
|
@ -84,7 +84,7 @@ POST /projects/:id/releases/:tag_name/assets/links
|
|||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------- | -------------- | -------- | --------------------------------------- |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
|
||||
| `tag_name` | string | yes | The tag associated with the Release. |
|
||||
| `name` | string | yes | The name of the link. |
|
||||
| `url` | string | yes | The URL of the link. |
|
||||
|
@ -120,7 +120,7 @@ PUT /projects/:id/releases/:tag_name/assets/links/:link_id
|
|||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------- | -------------- | -------- | --------------------------------------- |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
|
||||
| `tag_name` | string | yes | The tag associated with the Release. |
|
||||
| `link_id` | integer | yes | The id of the link. |
|
||||
| `name` | string | no | The name of the link. |
|
||||
|
@ -156,7 +156,7 @@ DELETE /projects/:id/releases/:tag_name/assets/links/:link_id
|
|||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------- | -------------- | -------- | --------------------------------------- |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
|
||||
| `tag_name` | string | yes | The tag associated with the Release. |
|
||||
| `link_id` | integer | yes | The id of the link. |
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ all within GitLab. All you need to do is define them in your project's
|
|||
history of your deployments per every environment.
|
||||
|
||||
Environments are like tags for your CI jobs, describing where code gets deployed.
|
||||
Deployments are created when [jobs] deploy versions of code to environments,
|
||||
Deployments are created when [jobs](yaml/README.md#introduction) deploy versions of code to environments,
|
||||
so every environment can have one or more deployments. GitLab keeps track of
|
||||
your deployments, so you always know what is currently being deployed on your
|
||||
servers. If you have a deployment service such as [Kubernetes][kube]
|
||||
|
@ -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-and-except-simplified) on the `master`
|
||||
- The `deploy_staging` job will run [only](yaml/README.md#onlyexcept-basic) 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`
|
||||
|
@ -298,8 +298,8 @@ here because it is guaranteed to be unique, but if you're using a workflow like
|
|||
environment names to be more closely based on the branch name - the example
|
||||
above would give you an URL like `https://100-do-the-thing.example.com`
|
||||
|
||||
Last but not least, we tell the job to run [`only`][only] on branches
|
||||
[`except`][only] master.
|
||||
Last but not least, we tell the job to run [`only`](yaml/README.md#onlyexcept-basic) on branches
|
||||
[`except`](yaml/README.md#onlyexcept-basic) master.
|
||||
|
||||
>**Note:**
|
||||
You are not bound to use the same prefix or only slashes in the dynamic
|
||||
|
@ -613,14 +613,12 @@ Below are some links you may find interesting:
|
|||
- [Review Apps - Use dynamic environments to deploy your code for every branch](review_apps/index.md)
|
||||
|
||||
[Pipelines]: pipelines.md
|
||||
[jobs]: yaml/README.md#jobs
|
||||
[yaml]: yaml/README.md
|
||||
[environments]: #environments
|
||||
[deployments]: #deployments
|
||||
[permissions]: ../user/permissions.md
|
||||
[variables]: variables/README.md
|
||||
[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
|
||||
|
|
|
@ -99,7 +99,7 @@ We've used the `java:8` [docker
|
|||
image](../../docker/using_docker_images.md) to build
|
||||
our application as it provides the up-to-date Java 8 JDK on [Docker
|
||||
Hub](https://hub.docker.com/). We've also added the [`only`
|
||||
clause](../../yaml/README.md#only-and-except-simplified)
|
||||
clause](../../yaml/README.md#onlyexcept-basic)
|
||||
to ensure our deployments only happen when we push to the master branch.
|
||||
|
||||
Now, since the steps defined in `.gitlab-ci.yml` require credentials to login
|
||||
|
|
|
@ -139,7 +139,7 @@ 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#jobs) that actually have a browser available.
|
||||
1. Set up [CI/CD jobs](../../yaml/README.md#introduction) that actually have a browser available.
|
||||
2. 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)
|
||||
|
@ -184,7 +184,7 @@ option as an argument to `npm run confidence-check` on the command line.
|
|||
However, we still need to tell WebdriverIO which browser is available for it to use.
|
||||
|
||||
[GitLab CI/CD makes
|
||||
a number of variables available](../../variables/README.html#predefined-variables-environment-variables)
|
||||
a number of variables available](../../variables/README.html#predefined-environment-variables)
|
||||
with information about the current CI job. We can use this information to dynamically set
|
||||
up our WebdriverIO configuration according to the job that is running. More specifically, we can
|
||||
tell WebdriverIO what browser to execute the test on depending on the name of the currently running
|
||||
|
|
|
@ -573,7 +573,7 @@ If any of the conditions in `variables` evaluates to truth when using `only`,
|
|||
a new job is going to be created. If any of the expressions evaluates to truth
|
||||
when `except` is being used, a job is not going to be created.
|
||||
|
||||
This follows usual rules for [`only` / `except` policies][builds-policies].
|
||||
This follows usual rules for [`only` / `except` policies](../yaml/README.md#onlyexcept-advanced).
|
||||
|
||||
### Supported syntax
|
||||
|
||||
|
@ -639,7 +639,6 @@ Below you can find supported syntax reference:
|
|||
[protected tags]: ../../user/project/protected_tags.md
|
||||
[shellexecutors]: https://docs.gitlab.com/runner/executors/
|
||||
[triggered]: ../triggers/README.md
|
||||
[builds-policies]: ../yaml/README.md#only-and-except-complex
|
||||
[gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
|
||||
[registry]: ../../user/project/container_registry.md
|
||||
[dependent-repositories]: ../../user/project/new_ci_build_permissions_model.md#dependent-repositories
|
||||
|
|
|
@ -423,7 +423,7 @@ If you use multiple keys under `only` or `except`, they act as an AND. The logic
|
|||
#### `only:refs`/`except:refs`
|
||||
|
||||
The `refs` strategy can take the same values as the
|
||||
[simplified only/except configuration](#only-and-except-simplified).
|
||||
[simplified only/except configuration](#onlyexcept-basic).
|
||||
|
||||
In the example below, the `deploy` job is going to be created only when the
|
||||
pipeline has been [scheduled][schedules] or runs for the `master` branch:
|
||||
|
|
|
@ -78,7 +78,7 @@ For issues requiring any new or updated documentation, the Product Manager (PM)
|
|||
must:
|
||||
|
||||
- Add the `Documentation` label.
|
||||
- Confirm or add the [documentation requirements](#documentation-requirements).
|
||||
- Confirm or add the [documentation requirements](#documentation-requirements-in-feature-issues).
|
||||
- Ensure the issue contains any new or updated feature name, overview/description,
|
||||
and use cases, as required per the [documentation structure and template](structure.md), when applicable.
|
||||
|
||||
|
|
|
@ -20,7 +20,7 @@ From now on, every existing project and newly created ones that don't have a
|
|||
`.gitlab-ci.yml`, will use the Auto DevOps pipelines.
|
||||
|
||||
If you want to disable it for a specific project, you can do so in
|
||||
[its settings](../../../topics/autodevops/index.md##enablingdisabling-auto-devops).
|
||||
[its settings](../../../topics/autodevops/index.md#enablingdisabling-auto-devops).
|
||||
|
||||
## Maximum artifacts size **[CORE ONLY]**
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ You can leave a comment in the following places:
|
|||
- commit diffs
|
||||
|
||||
There are standard comments, and you also have the option to create a comment
|
||||
in the form of a threaded discussion. A comment can also be [turned into a discussion](#start-a-discussion-by-replying-to-a-non-discussion-comment)
|
||||
in the form of a threaded discussion. A comment can also be [turned into a discussion](#start-a-discussion-by-replying-to-a-standard-comment)
|
||||
when it receives a reply.
|
||||
|
||||
The comment area supports [Markdown] and [quick actions]. You can edit your own
|
||||
|
|
|
@ -125,7 +125,7 @@ merge requests, code snippets, and commits.
|
|||
|
||||
When performing inline reviews to implementations
|
||||
to your codebase through merge requests you can
|
||||
gather feedback through [resolvable discussions](discussions/index.md#resolvable-discussions).
|
||||
gather feedback through [resolvable discussions](discussions/index.md#resolvable-comments-and-discussions).
|
||||
|
||||
### GitLab Flavored Markdown (GFM)
|
||||
|
||||
|
|
|
@ -69,7 +69,7 @@ new Kubernetes cluster to your project:
|
|||
- **Number of nodes** - Enter the number of nodes you wish the cluster to have.
|
||||
- **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
|
||||
of the Virtual Machine instance that the cluster will be based on.
|
||||
- **RBAC-enabled cluster** - Leave this checked if using default GKE creation options, see the [RBAC section](#role-based-access-control-rbac-core-only) for more information.
|
||||
- **RBAC-enabled cluster** - Leave this checked if using default GKE creation options, see the [RBAC section](#role-based-access-control-rbac) for more information.
|
||||
1. Finally, click the **Create Kubernetes cluster** button.
|
||||
|
||||
After a couple of minutes, your cluster will be ready to go. You can now proceed
|
||||
|
|
|
@ -24,7 +24,7 @@ one for the first time.**
|
|||
[GitLab CI/CD](../../../ci/README.md) serves
|
||||
numerous purposes, to build, test, and deploy your app
|
||||
from GitLab through
|
||||
[Continuous Integration, Continuous Delivery, and Continuous Deployment](../../../ci/introduction/index.md#introduction-to-continuous-methods)
|
||||
[Continuous Integration, Continuous Delivery, and Continuous Deployment](../../../ci/introduction/index.md#introduction-to-cicd-methodologies)
|
||||
methods. You will need it to build your website with GitLab Pages,
|
||||
and deploy it to the Pages server.
|
||||
|
||||
|
|
|
@ -152,7 +152,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-simplified),
|
||||
`pages` job with the [`only` parameter](../../../ci/yaml/README.md#onlyexcept-basic),
|
||||
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:
|
||||
|
@ -253,7 +253,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-simplified),
|
||||
the `pages` job with the [`only` parameter](../../../ci/yaml/README.md#onlyexcept-basic),
|
||||
whenever a new commit is pushed to a branch that will be used specifically for
|
||||
your pages.
|
||||
|
||||
|
|
|
@ -59,7 +59,7 @@ GitLab CI so that they can be used in your `.gitlab-ci.yml` file.
|
|||
|
||||
To configure that a job can be executed only when the pipeline has been
|
||||
scheduled (or the opposite), you can use
|
||||
[only and except](../../../ci/yaml/README.md#only-and-except-simplified) configuration keywords.
|
||||
[only and except](../../../ci/yaml/README.md#onlyexcept-basic) configuration keywords.
|
||||
|
||||
```
|
||||
job:on-schedule:
|
||||
|
|
|
@ -20,7 +20,7 @@ and private. See [Public access](../public_access/public_access.md) for more inf
|
|||
## Project snippets
|
||||
|
||||
Project snippets are always related to a specific project.
|
||||
See [Project's features](project/index.md#projects-features) for more information.
|
||||
See [Project features](project/index.md#project-features) for more information.
|
||||
|
||||
## Discover snippets
|
||||
|
||||
|
|
Loading…
Reference in New Issue