diff --git a/doc/ci/environments.md b/doc/ci/environments.md index 54493bc29222fd90c6cbd9895ecca82c3e430fd2..eaafc7bc1c04c84cc7d69e13640e63319b6804c1 100644 --- a/doc/ci/environments.md +++ b/doc/ci/environments.md @@ -664,7 +664,7 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/* ### Scoping environments with specs **[PREMIUM]** Some GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) features can behave differently for each -environment. For example, you can [create a secret variable to be injected only into a production environment](variables/README.md#limiting-environment-scopes-of-variables-premium). +environment. For example, you can [create a secret variable to be injected only into a production environment](https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-environment-variables-premium). In most cases, these features use the _environment specs_ mechanism, which offers an efficient way to implement scoping within each environment group. diff --git a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md index 908cf85980e402319afbfbbba42b8b0564e1160d..d6ad00a77da840cc9815ce3fe71e39046cf99c26 100644 --- a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md +++ b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md @@ -511,7 +511,7 @@ Errors can be easily debugged through GitLab's build logs, and within minutes of you can see the changes live on your game. Setting up Continuous Integration and Continuous Deployment from the start with Dark Nova enables -rapid but stable development. We can easily test changes in a separate [environment](../../../ci/environments.md#introduction-to-environments-and-deployments), +rapid but stable development. We can easily test changes in a separate [environment](../../environments.md), or multiple environments if needed. Balancing and updating a multiplayer game can be ongoing and tedious, but having faith in a stable deployment with GitLab CI/CD allows a lot of breathing room in quickly getting changes to players. diff --git a/doc/ci/introduction/index.md b/doc/ci/introduction/index.md index d505f2ae4ce3edf0bb7dcb7130047f0c56f06425..6055d8c282a835fe6e993b0a05d74830c19f62c8 100644 --- a/doc/ci/introduction/index.md +++ b/doc/ci/introduction/index.md @@ -127,7 +127,7 @@ displayed by GitLab: ![pipeline status](img/pipeline_status.png) At the end, if anything goes wrong, you can easily -[roll back](../environments.md#rolling-back-changes) all the changes: +[roll back](../environments.md#retrying-and-rolling-back) all the changes: ![rollback button](img/rollback.png) diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md index 38cd58f11ac56b1e382a9cde4a0e392ea0415e65..2ffa3d4edc7e8abdbce5c4b59ad023ebab228df9 100644 --- a/doc/ci/pipelines.md +++ b/doc/ci/pipelines.md @@ -295,7 +295,7 @@ You can do this straight from the pipeline graph. Just click on the play button to execute that particular job. For example, your pipeline start automatically, but require manual action to -[deploy to production](environments.md#manually-deploying-to-environments). In the example below, the `production` +[deploy to production](environments.md#configuring-manual-deployments). In the example below, the `production` stage has a job with a manual action. ![Pipelines example](img/pipelines.png) @@ -313,7 +313,7 @@ For example, if you start rolling out new code and: - Users do not experience trouble, GitLab can automatically complete the deployment from 0% to 100%. - Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline - and [rolling](environments.md#rolling-back-changes) back to the last stable version. + and [rolling](environments.md#retrying-and-rolling-back) back to the last stable version. ![Pipelines example](img/pipeline_incremental_rollout.png) diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md index 53651a807c23b5818425dd02037c0560d3934dc1..2fc1e14f02e8e5369e6f9274aa371077d9e5133c 100644 --- a/doc/ci/review_apps/index.md +++ b/doc/ci/review_apps/index.md @@ -33,7 +33,7 @@ In this example, you can see a branch was: ## How do Review Apps work? -The basis of Review Apps in GitLab is [dynamic environments](../environments.md#dynamic-environments), which allow you to dynamically create a new environment for each branch. +The basis of Review Apps in GitLab is [dynamic environments](../environments.md#configuring-dynamic-environments), which allow you to dynamically create a new environment for each branch. Access to the Review App is made available as a link on the [merge request](../../user/project/merge_requests.md) relevant to the branch. Review Apps enable you to review all changes proposed by the merge request in live environment. @@ -60,14 +60,14 @@ To get a better understanding of Review Apps, review documentation on how enviro 1. Learn about [environments](../environments.md) and their role in the development workflow. 1. Learn about [CI variables](../variables/README.md) and how they can be used in your CI jobs. 1. Explore the [`environment` syntax](../yaml/README.md#environment) as defined in `.gitlab-ci.yml`. This will become a primary reference. -1. Additionally, find out about [manual actions](../environments.md#manually-deploying-to-environments) and how you can use them to deploy to critical environments like production with the push of a button. +1. Additionally, find out about [manual actions](../environments.md#configuring-manual-deployments) and how you can use them to deploy to critical environments like production with the push of a button. 1. Follow the [example tutorials](#examples). These will guide you through setting up infrastructure and using Review Apps. ### Configuring dynamic environments Configuring Review Apps dynamic environments depends on your technology stack and infrastructure. -For more information, see [dynamic environments](../environments.md#dynamic-environments) documentation to understand how to define and create them. +For more information, see [dynamic environments](../environments.md#configuring-dynamic-environments) documentation to understand how to define and create them. ### Creating and destroying Review Apps diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index d52312371cdd9a8e7abc62468c9b454d69b93d51..cf2189cd00a1f0ba2daefb41902d8c9a57063932 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -756,7 +756,7 @@ Manual actions are a special type of job that are not executed automatically, they need to be explicitly started by a user. An example usage of manual actions would be a deployment to a production environment. Manual actions can be started from the pipeline, job, environment, and deployment views. Read more at the -[environments documentation](../environments.md#manually-deploying-to-environments). +[environments documentation](../environments.md#configuring-manual-deployments). Manual actions can be either optional or blocking. Blocking manual actions will block the execution of the pipeline at the stage this action is defined in. It's diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 7693109b3c4c5f43b5abb7f5d5aaf7054a80dfa9..9060360e6a284f12a9185b03665cb4ecdc9f50dc 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -955,7 +955,7 @@ required to go from `10%` to `100%`, you can jump to whatever job you want. You can also scale down by running a lower percentage job, just before hitting `100%`. Once you get to `100%`, you cannot scale down, and you'd have to roll back by redeploying the old version using the -[rollback button](../../ci/environments.md#rolling-back-changes) in the +[rollback button](../../ci/environments.md#retrying-and-rolling-back) in the environment page. Below, you can see how the pipeline will look if the rollout or staging