diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md index 8a39d87fb8e8f760e5f1a3d215eed5aea9a6a003..01f514ebe15af7869cbe5dd5dfb025d2cf4b1d1c 100644 --- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md +++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md @@ -39,7 +39,7 @@ your Git repository via URL. ![Bitbucket Cloud webhook](img/bitbucket_app_password.png) -1. In GitLab from **Settings > CI/CD > Secret variables** add variables to allow +1. In GitLab from **Settings > CI/CD > Variables** add variables to allow communication with Bitbucket via the Bitbucket API. `BITBUCKET_ACCESS_TOKEN`: the Bitbucket app password created above diff --git a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/img/cloud_foundry_secret_variables.png b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/img/cloud_foundry_secret_variables.png deleted file mode 100644 index 5b5d91ec07a649ffa9b94327c2491fbc12a87bc5..0000000000000000000000000000000000000000 Binary files a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/img/cloud_foundry_secret_variables.png and /dev/null differ diff --git a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/img/cloud_foundry_variables.png b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/img/cloud_foundry_variables.png new file mode 100644 index 0000000000000000000000000000000000000000..28323e2d8deb0bcea5af18b199b4d49c0184aa4d Binary files /dev/null and b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/img/cloud_foundry_variables.png differ diff --git a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md index b88761be56b388d7f98c741f7776e89723238c58..3ea81be1569f7db48c0898f40477cc9ba9797543 100644 --- a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md +++ b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md @@ -106,10 +106,10 @@ Now, since the steps defined in `.gitlab-ci.yml` require credentials to login to CF, you'll need to add your CF credentials as [environment variables](../../variables/README.md#predefined-variables-environment-variables) on GitLab CI/CD. To set the environment variables, navigate to your project's -**Settings > CI/CD** and expand **Secret Variables**. Name the variables +**Settings > CI/CD** and expand **Variables**. Name the variables `CF_USERNAME` and `CF_PASSWORD` and set them to the correct values. -![Secret Variable Settings in GitLab](img/cloud_foundry_secret_variables.png) +![Variable Settings in GitLab](img/cloud_foundry_variables.png) Once set up, GitLab CI/CD will deploy your app to CF at every push to your repository's deafult branch. To see the build logs or watch your builds running diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md index f53f7c5028106b59b246838b2409e93306d1a0ac..46effb76d710834dbe1ed0259058577f31238df1 100644 --- a/doc/ci/examples/deployment/README.md +++ b/doc/ci/examples/deployment/README.md @@ -101,12 +101,12 @@ production: We created two deploy jobs that are executed on different events: 1. `staging` is executed for all commits that were pushed to `master` branch, -2. `production` is executed for all pushed tags. +1. `production` is executed for all pushed tags. We also use two secure variables: 1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app, -2. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app. +1. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app. ## Storing API keys @@ -120,7 +120,7 @@ is hidden in the job log. You access added variable by prefixing it's name with `$` (on non-Windows runners) or `%` (for Windows Batch runners): -1. `$SECRET_VARIABLE` - use it for non-Windows runners -2. `%SECRET_VARIABLE%` - use it for Windows Batch runners +1. `$VARIABLE` - use it for non-Windows runners +1. `%VARIABLE%` - use it for Windows Batch runners Read more about the [CI variables](../../variables/README.md). diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md index bed379b0254eaa3c0686234ecb128d2048f75cb7..2f4d46c0d80e1217d873fd01dd43716f46598b69 100644 --- a/doc/ci/examples/deployment/composer-npm-deploy.md +++ b/doc/ci/examples/deployment/composer-npm-deploy.md @@ -43,7 +43,7 @@ All these operations will put all files into a `build` folder, which is ready to You have multiple options: rsync, scp, sftp and so on. For now, we will use scp. -To make this work, you need to add a GitLab Secret Variable (accessible on _gitlab.example/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** ssh key of your server. +To make this work, you need to add a GitLab CI/CD variable, by navigating to your project's **Settings > CI/CD** and expanding **Variables**. That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** ssh key of your server. ### Security tip 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 b75ed87bc914c240b3a50d1c45a392373491c3fc..cae051daa56c5d0ba476974b9d7c89eb990e11af 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 @@ -418,7 +418,7 @@ fully understand [IAM Best Practices in AWS](http://docs.aws.amazon.com/IAM/late 1. Click the **Access Keys** section and **Create New Access Key**. Create the key and keep the id and secret around, you'll need them later ![AWS Access Key Config](img/aws_config_window.png) 1. Go to your GitLab project, click **Settings > CI/CD** on the left sidebar -1. Expand the **Secret Variables** section +1. Expand the **Variables** section ![GitLab Secret Config](img/gitlab_config.png) 1. Add a key named `AWS_KEY_ID` and copy the key id from Step 2 into the **Value** textbox 1. Add a key named `AWS_KEY_SECRET` and copy the key secret from Step 2 into the **Value** textbox diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/img/secret_variables_page.png b/doc/ci/examples/laravel_with_gitlab_and_envoy/img/secret_variables_page.png deleted file mode 100644 index b7906d49dcb9031f06ea39c2a44cad41fe7736b6..0000000000000000000000000000000000000000 Binary files a/doc/ci/examples/laravel_with_gitlab_and_envoy/img/secret_variables_page.png and /dev/null differ diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/img/variables_page.png b/doc/ci/examples/laravel_with_gitlab_and_envoy/img/variables_page.png new file mode 100644 index 0000000000000000000000000000000000000000..80d8eb0f4fc97dc3d6f59defc6f33f2a26159a9a Binary files /dev/null and b/doc/ci/examples/laravel_with_gitlab_and_envoy/img/variables_page.png differ diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md index 70020d461d9de8af4bcb3f67b5c0f78580091c50..b6989d229d1346b56febba4e132a15455f9fb2e0 100644 --- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md +++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md @@ -120,12 +120,12 @@ Now, let's add it to your GitLab project as a [variable](../../variables/README. Variables are user-defined variables and are stored out of `.gitlab-ci.yml`, for security purposes. They can be added per project by navigating to the project's **Settings** > **CI/CD**. -![variables page](img/secret_variables_page.png) - To the field **KEY**, add the name `SSH_PRIVATE_KEY`, and to the **VALUE** field, paste the private key you've copied earlier. We'll use this variable in the `.gitlab-ci.yml` later, to easily connect to our remote server as the deployer user without entering its password. -We also need to add the public key to **Project** > **Settings** > **Repository** as [Deploy Keys](../../../ssh/README.md#deploy-keys), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project). +![variables page](img/variables_page.png) + +We also need to add the public key to **Project** > **Settings** > **Repository** as a [Deploy Key](../../../ssh/README.md#deploy-keys), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project). ```bash @@ -135,10 +135,10 @@ We also need to add the public key to **Project** > **Settings** > **Repository* cat ~/.ssh/id_rsa.pub ``` -![deploy keys page](img/deploy_keys_page.png) - To the field **Title**, add any name you want, and paste the public key into the **Key** field. +![deploy keys page](img/deploy_keys_page.png) + Now, let's clone our repository on the server just to make sure the `deployer` user has access to the repository. ```bash diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md index 8c3ab7643ba2b96a35746317ab62363629eaf95e..60c539c4decdc6b74af2a02b19b4c1f0b3333959 100644 --- a/doc/development/documentation/styleguide.md +++ b/doc/development/documentation/styleguide.md @@ -409,7 +409,7 @@ You can use the following fake tokens as examples. | Personal access token | `n671WNGecHugsdEDPsyo` | | Application ID | `2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6` | | Application secret | `04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df` | -| Secret CI variable | `Li8j-mLUVA3eZYjPfd_H` | +| CI/CD variable | `Li8j-mLUVA3eZYjPfd_H` | | Specific Runner token | `yrnZW46BrtBFqM7xDzE7dddd` | | Shared Runner token | `6Vk7ZsosqQyfreAxXTZr` | | Trigger token | `be20d8dcc028677c931e04f3871a9b` | diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 9ecca5bacaed934a4c079074b602d07db6f196c0..0efb4c162b1f099bf730cf1b0ec9e54ba92a00c5 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -586,7 +586,7 @@ repo or by specifying a project variable: file in it, Auto DevOps will detect the chart and use it instead of the [default one](https://gitlab.com/charts/auto-deploy-app). This can be a great way to control exactly how your application is deployed. -- **Project variable** - Create a [project variable](../../ci/variables/README.md#secret-variables) +- **Project variable** - Create a [project variable](../../ci/variables/README.md#variables) `AUTO_DEVOPS_CHART` with the URL of a custom chart to use. ### Customizing `.gitlab-ci.yml` @@ -660,7 +660,7 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac TIP: **Tip:** Set up the replica variables using a -[project variable](../../ci/variables/README.md#secret-variables) +[project variable](../../ci/variables/README.md#variables) and scale your application by just redeploying it! CAUTION: **Caution:** @@ -738,7 +738,7 @@ staging environment and deploy to production manually. For this scenario, the `STAGING_ENABLED` environment variable was introduced. If `STAGING_ENABLED` is defined in your project (e.g., set `STAGING_ENABLED` to -`1` as a secret variable), then the application will be automatically deployed +`1` as a CI/CD variable), then the application will be automatically deployed to a `staging` environment, and a `production_manual` job will be created for you when you're ready to manually deploy to production. @@ -751,7 +751,7 @@ A [canary environment](https://docs.gitlab.com/ee/user/project/canary_deployment before any changes are deployed to production. If `CANARY_ENABLED` is defined in your project (e.g., set `CANARY_ENABLED` to -`1` as a secret variable) then two manual jobs will be created: +`1` as a CI/CD variable) then two manual jobs will be created: - `canary` which will deploy the application to the canary environment - `production_manual` which is to be used by you when you're ready to manually