Some GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) features can
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
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-environment-variables-premium).
You can limit the environment scope of a variable by
defining which environments it can be available for.
Wildcards can be used, and the default environment scope is `*`, which means
any jobs will have this variable, not matter if an environment is defined or
not.
For example, if the environment scope is `production`, then only the jobs
having the environment `production` defined would have this specific variable.
Wildcards (`*`) can be used along with the environment name, therefore if the
environment scope is `review/*` then any jobs with environment names starting
with `review/` would have that particular variable.
Some GitLab 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-environment-variables-premium). **[PREMIUM]**
In most cases, these features use the _environment specs_ mechanism, which offers
In most cases, these features use the _environment specs_ mechanism, which offers
an efficient way to implement scoping within each environment group.
an efficient way to implement scoping within each environment group.
...
@@ -693,7 +712,7 @@ Each environment can be matched with the following environment spec:
...
@@ -693,7 +712,7 @@ Each environment can be matched with the following environment spec:
As you can see, you can use specific matching for selecting a particular environment,
As you can see, you can use specific matching for selecting a particular environment,
and also use wildcard matching (`*`) for selecting a particular environment group,
and also use wildcard matching (`*`) for selecting a particular environment group,
such as [Review apps](review_apps/index.md)(`review/*`).
such as [Review Apps](review_apps/index.md)(`review/*`).
NOTE: **Note:**
NOTE: **Note:**
The most _specific_ spec takes precedence over the other wildcard matching.
The most _specific_ spec takes precedence over the other wildcard matching.
...
@@ -712,3 +731,15 @@ Below are some links you may find interesting:
...
@@ -712,3 +731,15 @@ Below are some links you may find interesting:
-[A blog post on Deployments & Environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/)
-[A blog post on Deployments & Environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/)
-[Review Apps - Use dynamic environments to deploy your code for every branch](review_apps/index.md)
-[Review Apps - Use dynamic environments to deploy your code for every branch](review_apps/index.md)
-[Deploy Boards for your applications running on Kubernetes](https://docs.gitlab.com/ee/user/project/deploy_boards.html)**[PREMIUM]**
-[Deploy Boards for your applications running on Kubernetes](https://docs.gitlab.com/ee/user/project/deploy_boards.html)**[PREMIUM]**
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
