kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Rename Secret variables -> variables

Browse source
This commit is contained in:
Achilleas Pipinellis 2018-05-31 18:41:37 +02:00
parent bb6b73cf3c
commit 3c9686c96d
No known key found for this signature in database
GPG key ID: A0996FBD3E92C17B
20 changed files with 61 additions and 61 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
app/views/groups/settings/ci_cd/show.html.haml
View file

@ -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

2
app/views/projects/settings/ci_cd/show.html.haml
View file

@ -43,7 +43,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.js-settings-toggle{ type: 'button' }
= expanded ? 'Collapse' : 'Expand'
%p.append-bottom-0

2
doc/README.md
View file

@ -162,7 +162,7 @@ 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)
### Monitor

4
doc/ci/docker/using_docker_images.md
View file

@ -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/

2
doc/ci/environments.md
View file

@ -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

10
doc/ci/examples/artifactory_and_gitlab/index.md
View file

@ -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.

2
doc/ci/examples/deployment/README.md
View file

@ -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

4
doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
View file

@ -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

6
doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
View file

@ -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.

2
doc/ci/pipelines.md
View file

@ -258,7 +258,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.

8
doc/ci/ssh_keys/README.md
View file

@ -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,

2
doc/ci/triggers/README.md
View file

@ -53,7 +53,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:

46
doc/ci/variables/README.md
View file

@ -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
@ -165,49 +165,49 @@ 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.
@ -231,7 +231,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!
@ -419,7 +419,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
@ -472,7 +472,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
@ -550,7 +550,7 @@ 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.
[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"
[eep]: https://about.gitlab.com/products/ "Available only in GitLab Premium"
[envs]: ../environments.md
[protected branches]: ../../user/project/protected_branches.md

6
doc/ci/variables/where_variables_can_be_used.md
View file

@ -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"`:

4
doc/ci/yaml/README.md
View file

@ -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.
@ -1249,7 +1249,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]

2
doc/development/doc_styleguide.md
View file

@ -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.

2
doc/downgrade_ee_to_ce/README.md
View file

@ -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

4
doc/raketasks/backup_restore.md
View file

@ -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.

10
doc/topics/autodevops/index.md
View file

@ -437,7 +437,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`
@ -507,7 +507,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:**
@ -582,7 +582,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.
@ -595,7 +595,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
@ -611,7 +611,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:

2
doc/user/project/clusters/index.md
View file

@ -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