Merge branch 'secret-variables-name-ee' into 'master'

Rename Secret variables -> variables

Closes gitlab-ce#38479

See merge request gitlab-org/gitlab-ee!5933

app/views/groups/settings/ci_cd/show.html.haml

@@ -7,7 +7,7 @@
   .settings-header
     %h4
       = _('Variables')
-      = link_to icon('question-circle'), help_page_path('ci/variables/README', anchor: 'secret-variables'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to icon('question-circle'), help_page_path('ci/variables/README', anchor: 'variables'), target: '_blank', rel: 'noopener noreferrer'
     %button.btn.btn-default.js-settings-toggle{ type: "button" }
       = expanded ? _('Collapse') : _('Expand')
     %p.append-bottom-0

doc/README.md

@@ -184,10 +184,10 @@ configuration. Then customize everything from buildpacks to CI/CD.
 
 - [Auto DevOps](topics/autodevops/index.md)
 - [Deployment of Helm, Ingress, and Prometheus on Kubernetes](user/project/clusters/index.md#installing-applications)
-- [Protected secret variables](ci/variables/README.md#protected-secret-variables)
+- [Protected variables](ci/variables/README.md#protected-variables)
 - [Easy creation of Kubernetes clusters on GKE](user/project/clusters/index.md#adding-and-creating-a-new-gke-cluster-via-gitlab)
 - [Multiple Kubernetes Clusters](user/project/clusters/index.md#multiple-kubernetes-clusters) **[PREMIUM]**
-- [Environment-specific secret variables](ci/variables/README.md#limiting-environment-scopes-of-secret-variables) **[PREMIUM]**
+- [Environment-specific variables](ci/variables/README.md#limiting-environment-scopes-of-variables) **[PREMIUM]**
 
 ### Monitor
 

doc/ci/docker/using_docker_images.md

@@ -496,7 +496,7 @@ To configure access for `registry.example.com`, follow these steps:
            bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ=
            ```
 
-1. Create a [secret variable] `DOCKER_AUTH_CONFIG` with the content of the
+1. Create a [variable] `DOCKER_AUTH_CONFIG` with the content of the
    Docker configuration file as the value:
 
      ```json
@@ -632,7 +632,7 @@ creation.
 [postgres-hub]: https://hub.docker.com/r/_/postgres/
 [mysql-hub]: https://hub.docker.com/r/_/mysql/
 [runner-priv-reg]: http://docs.gitlab.com/runner/configuration/advanced-configuration.html#using-a-private-container-registry
-[secret variable]: ../variables/README.md#secret-variables
+[variable]: ../variables/README.md#variables
 [entrypoint]: https://docs.docker.com/engine/reference/builder/#entrypoint
 [cmd]: https://docs.docker.com/engine/reference/builder/#cmd
 [register]: https://docs.gitlab.com/runner/register/

doc/ci/environments.md

@@ -249,7 +249,7 @@ the basis of [Review apps](review_apps/index.md).
 NOTE: **Note:**
 The `name` and `url` parameters can use most of the CI/CD variables,
 including [predefined](variables/README.md#predefined-variables-environment-variables),
-[secret](variables/README.md#secret-variables) and
+[project/group ones](variables/README.md#variables) and
 [`.gitlab-ci.yml` variables](yaml/README.md#variables). You however cannot use variables
 defined under `script` or on the Runner's side. There are also other variables that
 are unsupported in the context of `environment:name`. You can read more about

doc/ci/examples/artifactory_and_gitlab/index.md

@@ -58,7 +58,7 @@ The application is ready to use, but you need some additional steps to deploy it
 1. Log in to Artifactory with your user's credentials.
 1. From the main screen, click on the `libs-release-local` item in the **Set Me Up** panel.
 1. Copy to clipboard the configuration snippet under the **Deploy** paragraph.
-1. Change the `url` value in order to have it configurable via secret variables.
+1. Change the `url` value in order to have it configurable via variables.
 1. Copy the snippet in the `pom.xml` file for your project, just after the
    `dependencies` section. The snippet should look like this:
 
@@ -98,7 +98,7 @@ parameter in `.gitlab-ci.yml` to use the custom location instead of the default
     </settings>
     ```
 
-    Username and password will be replaced by the correct values using secret variables.
+    Username and password will be replaced by the correct values using variables.
 
 ### Configure GitLab CI/CD for `simple-maven-dep`
 
@@ -107,8 +107,8 @@ Now it's time we set up [GitLab CI/CD](https://about.gitlab.com/features/gitlab-
 GitLab CI/CD uses a file in the root of the repo, named `.gitlab-ci.yml`, to read the definitions for jobs
 that will be executed by the configured GitLab Runners. You can read more about this file in the [GitLab Documentation](https://docs.gitlab.com/ee/ci/yaml/).
 
-First of all, remember to set up secret variables for your deployment. Navigate to your project's **Settings > CI/CD** page
-and add the following secret variables (replace them with your current values, of course):
+First of all, remember to set up variables for your deployment. Navigate to your project's **Settings > CI/CD > Variables** page
+and add the following ones (replace them with your current values, of course):
 
 - **MAVEN_REPO_URL**: `http://artifactory.example.com:8081/artifactory` (your Artifactory URL)
 - **MAVEN_REPO_USER**: `gitlab` (your Artifactory username)
@@ -156,7 +156,7 @@ by running all Maven phases in a sequential order, therefore, executing `mvn tes
 
 Both `build` and `test` jobs leverage the `mvn` command to compile the application and to test it as defined in the test suite that is part of the application.
 
-Deploy to Artifactory is done as defined by the secret variables we have just set up.
+Deploy to Artifactory is done as defined by the variables we have just set up.
 The deployment occurs only if we're pushing or merging to `master` branch, so that the development versions are tested but not published.
 
 Done! Now you have all the changes in the GitLab repo, and a pipeline has already been started for this commit. In the **Pipelines** tab you can see what's happening.

doc/ci/examples/deployment/README.md

@@ -111,7 +111,7 @@ We also use two secure variables:
 ## Storing API keys
 
 Secure Variables can added by going to your project's
-**Settings ➔ CI / CD ➔ Secret variables**. The variables that are defined
+**Settings ➔ CI / CD ➔ Variables**. The variables that are defined
 in the project settings are sent along with the build script to the Runner.
 The secure variables are stored out of the repository. Never store secrets in
 your project's `.gitlab-ci.yml`. It is also important that the secret's value

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -406,7 +406,7 @@ and further delves into the principles of GitLab CI/CD than discussed in this ar
 
 We need to be able to deploy to AWS with our AWS account credentials, but we certainly
 don't want to put secrets into source code. Luckily GitLab provides a solution for this
-with [Secret Variables](../../../ci/variables/README.md). This can get complicated
+with [Variables](../../../ci/variables/README.md). This can get complicated
 due to [IAM](https://aws.amazon.com/iam/) management. As a best practice, you shouldn't
 use root security credentials. Proper IAM credential management is beyond the scope of this
 article, but AWS will remind you that using root credentials is unadvised and against their
@@ -428,7 +428,7 @@ fully understand [IAM Best Practices in AWS](http://docs.aws.amazon.com/IAM/late
 To deploy our build artifacts, we need to install the [AWS CLI](https://aws.amazon.com/cli/) on
 the Shared Runner. The Shared Runner also needs to be able to authenticate with your AWS
 account to deploy the artifacts. By convention, AWS CLI will look for `AWS_ACCESS_KEY_ID`
-and `AWS_SECRET_ACCESS_KEY`. GitLab's CI gives us a way to pass the secret variables we
+and `AWS_SECRET_ACCESS_KEY`. GitLab's CI gives us a way to pass the variables we
 set up in the prior section using the `variables` portion of the `deploy` job. At the end,
 we add directives to ensure deployment `only` happens on pushes to `master`. This way, every
 single branch still runs through CI, and only merging (or committing directly) to master will

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -116,11 +116,11 @@ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
 cat ~/.ssh/id_rsa
 ```
 
-Now, let's add it to your GitLab project as a [secret variable](../../variables/README.md#secret-variables).
-Secret variables are user-defined variables and are stored out of `.gitlab-ci.yml`, for security purposes.
+Now, let's add it to your GitLab project as a [variable](../../variables/README.md#variables).
+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**.
 
-![secret variables page](img/secret_variables_page.png)
+![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.

doc/ci/pipelines.md

@@ -263,7 +263,7 @@ on that specific branch:
 - trigger **manual actions** on existing pipelines
 - **retry/cancel** existing jobs (using Web UI or Pipelines API)
 
-**Secret variables** marked as **protected** are accessible only to jobs that
+**Variables** marked as **protected** are accessible only to jobs that
 run on protected branches, avoiding untrusted users to get unintended access to
 sensitive information like deployment credentials and tokens.
 

doc/ci/ssh_keys/README.md

@@ -25,7 +25,7 @@ with any type of [executor](https://docs.gitlab.com/runner/executors/)
 ## How it works
 
 1. Create a new SSH key pair locally with [ssh-keygen](http://linux.die.net/man/1/ssh-keygen)
-1. Add the private key as a [secret variable](../variables/README.md) to
+1. Add the private key as a [variable](../variables/README.md) to
    your project
 1. Run the [ssh-agent](http://linux.die.net/man/1/ssh-agent) during job to load
    the private key.
@@ -49,7 +49,7 @@ to access it. This is where an SSH key pair comes in handy.
    **Do not** add a passphrase to the SSH key, or the `before_script` will\
    prompt for it.
 
-1. Create a new [secret variable](../variables/README.md#secret-variables).
+1. Create a new [variable](../variables/README.md#variables).
    As **Key** enter the name `SSH_PRIVATE_KEY` and in the **Value** field paste
    the content of your _private_ key that you created earlier.
 
@@ -157,7 +157,7 @@ ssh-keyscan example.com
 ssh-keyscan 1.2.3.4
 ```
 
-Create a new [secret variable](../variables/README.md#secret-variables) with
+Create a new [variable](../variables/README.md#variables) with
 `SSH_KNOWN_HOSTS` as "Key", and as a "Value" add the output of `ssh-keyscan`.
 
 NOTE: **Note:**
@@ -165,7 +165,7 @@ If you need to connect to multiple servers, all the server host keys
 need to be collected in the **Value** of the variable, one key per line.
 
 TIP: **Tip:**
-By using a secret variable instead of `ssh-keyscan` directly inside
+By using a variable instead of `ssh-keyscan` directly inside
 `.gitlab-ci.yml`, it has the benefit that you don't have to change `.gitlab-ci.yml`
 if the host domain name changes for some reason. Also, the values are predefined
 by you, meaning that if the host keys suddenly change, the CI/CD job will fail,

doc/ci/triggers/README.md

@@ -109,7 +109,7 @@ The action is irreversible.
   it will not trigger a job.
 - If your project is public, passing the token in plain text is probably not the
   wisest idea, so you might want to use a
-  [secret variable](../variables/README.md#secret-variables) for that purpose.
+  [variable](../variables/README.md#variables) for that purpose.
 
 To trigger a job you need to send a `POST` request to GitLab's API endpoint:
 

doc/ci/variables/README.md

@@ -10,17 +10,17 @@ The variables can be overwritten and they take precedence over each other in
 this order:
 
 1. [Trigger variables][triggers] or [scheduled pipeline variables](../../user/project/pipelines/schedules.md#making-use-of-scheduled-pipeline-variables) (take precedence over all)
-1. Project-level [secret variables](#secret-variables) or [protected secret variables](#protected-secret-variables)
-1. Group-level [secret variables](#secret-variables) or [protected secret variables](#protected-secret-variables)
+1. Project-level [variables](#variables) or [protected variables](#protected-variables)
+1. Group-level [variables](#variables) or [protected variables](#protected-variables)
 1. YAML-defined [job-level variables](../yaml/README.md#variables)
 1. YAML-defined [global variables](../yaml/README.md#variables)
 1. [Deployment variables](#deployment-variables)
 1. [Predefined variables](#predefined-variables-environment-variables) (are the
    lowest in the chain)
 
-For example, if you define `API_TOKEN=secure` as a secret variable and
+For example, if you define `API_TOKEN=secure` as a project variable and
 `API_TOKEN=yaml` in your `.gitlab-ci.yml`, the `API_TOKEN` will take the value
-`secure` as the secret variables are higher in the chain.
+`secure` as the project variables are higher in the chain.
 
 ## Unsupported variables
 
@@ -168,58 +168,58 @@ script:
   - 'eval $LS_CMD'  # will execute 'ls -al $TMP_DIR'
 ```
 
-## Secret variables
+## Variables
 
 NOTE: **Note:**
-Group-level secret variables were added in GitLab 9.4.
+Group-level variables were added in GitLab 9.4.
 
 CAUTION: **Important:**
-Be aware that secret variables are not masked, and their values can be shown
+Be aware that variables are not masked, and their values can be shown
 in the job logs if explicitly asked to do so. If your project is public or
 internal, you can set the pipelines private from your [project's Pipelines
 settings](../../user/project/pipelines/settings.md#visibility-of-pipelines).
-Follow the discussion in issue [#13784][ce-13784] for masking the secret variables.
+Follow the discussion in issue [#13784][ce-13784] for masking the variables.
 
-GitLab CI allows you to define per-project or per-group secret variables
-that are set in the pipeline environment. The secret variables are stored out of
+GitLab CI allows you to define per-project or per-group variables
+that are set in the pipeline environment. The variables are stored out of
 the repository (not in `.gitlab-ci.yml`) and are securely passed to GitLab Runner
 making them available during a pipeline run. It's the recommended method to
 use for storing things like passwords, SSH keys and credentials.
 
-Project-level secret variables can be added by going to your project's
-**Settings > CI/CD**, then finding the section called **Secret variables**.
+Project-level variables can be added by going to your project's
+**Settings > CI/CD**, then finding the section called **Variables**.
 
-Likewise, group-level secret variables can be added by going to your group's
-**Settings > CI/CD**, then finding the section called **Secret variables**.
+Likewise, group-level variables can be added by going to your group's
+**Settings > CI/CD**, then finding the section called **Variables**.
 Any variables of [subgroups] will be inherited recursively.
 
-![Secret variables](img/secret_variables.png)
+![Variables](img/secret_variables.png)
 
 Once you set them, they will be available for all subsequent pipelines. You can also
-[protect your variables](#protected-secret-variables).
+[protect your variables](#protected-variables).
 
-### Protected secret variables
+### Protected variables
 
 >**Notes:**
 This feature requires GitLab 9.3 or higher.
 
-Secret variables could be protected. Whenever a secret variable is
+Variables could be protected. Whenever a variable is
 protected, it would only be securely passed to pipelines running on the
 [protected branches] or [protected tags]. The other pipelines would not get any
 protected variables.
 
 Protected variables can be added by going to your project's
 **Settings > CI/CD**, then finding the section called
-**Secret variables**, and check "Protected".
+**Variables**, and check "Protected".
 
 Once you set them, they will be available for all subsequent pipelines.
 
-### Limiting environment scopes of secret variables **[PREMIUM]**
+### Limiting environment scopes of variables **[PREMIUM]**
 
 >**Notes:**
 [Introduced][ee-2112] in [GitLab Premium][premium] 9.4.
 
-You can limit the environment scope of a secret variable by
+You can limit the environment scope of a variable by
 [defining which environments][envs] it can be available for.
 
 Wildcards can be used, and the default environment scope is `*` which means
@@ -252,7 +252,7 @@ An example project service that defines deployment variables is the
 
 CAUTION: **Warning:**
 Enabling debug tracing can have severe security implications. The
-output **will** contain the content of all your secret variables and any other
+output **will** contain the content of all your variables and any other
 secrets! The output **will** be uploaded to the GitLab server and made visible
 in job traces!
 
@@ -440,7 +440,7 @@ job_name:
 ```
 
 You can also list all environment variables with the `export` command,
-but be aware that this will also expose the values of all the secret variables
+but be aware that this will also expose the values of all the variables
 you set, in the job log:
 
 ```yaml
@@ -493,7 +493,7 @@ It is possible to use variables expressions with only / except policies in
 `.gitlab-ci.yml`. By using this approach you can limit what jobs are going to
 be created within a pipeline after pushing a code to GitLab.
 
-This is particularly useful in combination with secret variables and triggered
+This is particularly useful in combination with variables and triggered
 pipeline variables.
 
 ```yaml
@@ -571,27 +571,8 @@ Below you can find supported syntax reference:
     Pattern matching is case-sensitive by default. Use `i` flag modifier, like
     `/pattern/i` to make a pattern case-insensitive.
 
-### Secret variables with an environment scope
-
-We do support secret variables defined with an environment scope. Given that
-there is a secret variable `$STAGING_SECRET` defined in a scope of
-`review/staging/*`, following job that is using dynamic environments feature,
-is going to be created, based on the matching variable expression:
-
-```yaml
-my-job:
-  stage: staging
-  environment:
-    name: review/$CI_JOB_STAGE/deploy
-  script:
-    - 'deploy staging'
-  only:
-    variables:
-      - $STAGING_SECRET == 'something'
-```
-
 [ee-2112]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2112
-[ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784 "Simple protection of CI secret variables"
+[ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784 "Simple protection of CI variables"
 [premium]: https://about.gitlab.com/products/ "Available only in GitLab Premium"
 [envs]: ../environments.md
 [protected branches]: ../../user/project/protected_branches.md

doc/ci/variables/where_variables_can_be_used.md

@@ -17,7 +17,7 @@ There are basically two places where you can use any defined variables:
 
 | Definition                           | Can be expanded?  | Expansion place | Description  |
 |--------------------------------------|-------------------|-----------------|--------------|
-| `environment:url`                    | yes               | GitLab           | The variable expansion is made by GitLab's [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism).<ul><li>**Supported:** all variables defined for a job (secret variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules)</li><li>**Not suported:** variables defined in Runner's `config.toml` and variables created in job's `script`</li></ul> |
+| `environment:url`                    | yes               | GitLab           | The variable expansion is made by GitLab's [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism).<ul><li>**Supported:** all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules)</li><li>**Not suported:** variables defined in Runner's `config.toml` and variables created in job's `script`</li></ul> |
 | `environment:name`                   | yes               | GitLab           | Similar to `environment:url`, but the variables expansion **doesn't support**: <ul><li>variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`)</li><li>any other variables related to environment (currently only `CI_ENVIRONMENT_URL`)</li><li>[persisted variables](#persisted-variables)</li></ul> |
 | `variables` | yes               | Runner          | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |
 | `image`          | yes               | Runner          | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |
@@ -55,7 +55,7 @@ since the expansion is done in GitLab before any Runner will get the job.
 
 ### GitLab Runner internal variable expansion mechanism
 
-- **Supported:** secret variables, `.gitlab-ci.yml` variables, `config.toml` variables, and
+- **Supported:** project/group variables, `.gitlab-ci.yml` variables, `config.toml` variables, and
   variables from triggers and pipeline schedules
 - **Not supported:** variables defined inside of scripts (e.g., `export MY_VARIABLE="test"`)
 
@@ -76,7 +76,7 @@ are using a different variables syntax.
 **Supported:**
 
 - The `script` may use all available variables that are default for the shell (e.g., `$PATH` which
-  should be present in all bash/sh shells) and all variables defined by GitLab CI/CD (secret variables,
+  should be present in all bash/sh shells) and all variables defined by GitLab CI/CD (project/group variables,
   `.gitlab-ci.yml` variables, `config.toml` variables, and variables from triggers and pipeline schedules).
 - The `script` may also use all variables defined in the lines before. So, for example, if you define
   a variable `export MY_VARIABLE="test"`:
@@ -112,10 +112,10 @@ They are:
   - by the definitions [described in the table](#gitlab-ci-yml-file) where the "Expansion place" is "GitLab"
   - in the `only` and `except` [variables expressions](README.md#variables-expressions)
 
-## Secret variables with an environment scope
+## Variables with an environment scope
 
-Secret variables defined with an environment scope are supported. Given that
-there is a secret variable `$STAGING_SECRET` defined in a scope of
+Variables defined with an environment scope are supported. Given that
+there is a variable `$STAGING_SECRET` defined in a scope of
 `review/staging/*`, the following job that is using dynamic environments
 is going to be created, based on the matching variable expression:
 

doc/ci/yaml/README.md

@@ -327,7 +327,7 @@ Refs strategy equals to simplified only/except configuration, whereas
 kubernetes strategy accepts only `active` keyword.
 
 `variables` keyword is used to define variables expressions. In other words
-you can use predefined variables / secret variables / project / group or
+you can use predefined variables / project / group or
 environment-scoped variables to define an expression GitLab is going to
 evaluate in order to decide whether a job should be created or not.
 
@@ -1428,7 +1428,7 @@ Runner itself](../variables/README.md#predefined-variables-environment-variables
 One example would be `CI_COMMIT_REF_NAME` which has the value of
 the branch or tag name for which project is built. Apart from the variables
 you can set in `.gitlab-ci.yml`, there are also the so called
-[secret variables](../variables/README.md#secret-variables)
+[Variables](../variables/README.md#variables)
 which can be set in GitLab's UI.
 
 [Learn more about variables and their priority.][variables]

doc/development/doc_styleguide.md

@@ -349,7 +349,7 @@ In this case:
 ### Fake tokens
 
 There may be times where a token is needed to demonstrate an API call using
-cURL or a secret variable used in CI. It is strongly advised not to use real
+cURL or a variable used in CI. It is strongly advised not to use real
 tokens in documentation even if the probability of a token being exploited is
 low.
 

doc/downgrade_ee_to_ce/README.md

@@ -57,7 +57,7 @@ $ sudo gitlab-rails runner "Service.where(type: ['JenkinsService', 'JenkinsDepre
 $ bundle exec rails runner "Service.where(type: ['JenkinsService', 'JenkinsDeprecatedService', 'GithubService']).delete_all" production
 ```
 
-### Secret variables environment scopes
+### Variables environment scopes
 
 If you're using this feature and there are variables sharing the same
 key, but they have different scopes in a project, then you might want to

doc/raketasks/backup_restore.md

@@ -492,8 +492,8 @@ directory (repositories, uploads).
 To restore a backup, you will also need to restore `/etc/gitlab/gitlab-secrets.json`
 (for Omnibus packages) or `/home/git/gitlab/.secret` (for installations
 from source). This file contains the database encryption key,
-[CI secret variables](../ci/variables/README.md#secret-variables), and
-secret variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md).
+[CI/CD variables](../ci/variables/README.md#variables), and
+variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md).
 If you fail to restore this encryption key file along with the application data
 backup, users with two-factor authentication enabled and GitLab Runners will
 lose access to your GitLab server.

doc/topics/autodevops/index.md

@@ -452,7 +452,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/charts.gitlab.io/tree/master/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 [variable](../../ci/variables/README.md#variables)
   `AUTO_DEVOPS_CHART` with the URL of a custom chart to use.
 
 ### Customizing `.gitlab-ci.yml`
@@ -524,7 +524,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:**
@@ -599,7 +599,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 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.
 
@@ -612,7 +612,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 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
@@ -628,7 +628,7 @@ This will allow you to first check how the app is behaving, and later manually
 increasing the rollout up to 100%.
 
 If `INCREMENTAL_ROLLOUT_ENABLED` is defined in your project (e.g., set
-`INCREMENTAL_ROLLOUT_ENABLED` to `1` as a secret variable), then instead of the
+`INCREMENTAL_ROLLOUT_ENABLED` to `1` as a variable), then instead of the
 standard `production` job, 4 different
 [manual jobs](../../ci/pipelines.md#manual-actions-from-the-pipeline-graph)
 will be created:

doc/user/project/clusters/index.md

@@ -233,7 +233,7 @@ When adding more than one Kubernetes clusters to your project, you need to
 differentiate them with an environment scope. The environment scope associates
 clusters and [environments](../../../ci/environments.md) in an 1:1 relationship
 similar to how the
-[environment-specific variables](../../../ci/variables/README.md#limiting-environment-scopes-of-secret-variables)
+[environment-specific variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables)
 work.
 
 The default environment scope is `*`, which means all jobs, regardless of their