Environment-specific variables

Description

Developers and Ops should be able to specify different values for secret (and not-so-secret) variables, and tie them to environments. For example, doing a deploy to Heroku might need an app name, which you could specify by $HEROKU_APP_NAME, but that name would be different in staging and production.

Proposal

• Add a scope to variables so that you could say var A applies to environment B.
• Support wildcards, so you could say that some deploy variable applies to review/* and all review apps would get the variable automatically.
• Default scope is *.
• If multiple scopes apply to an environment, more specific scopes should have priority over less-specific scopes. e.g. review/foo should have priority over review/*, which itself should have priority over *. This can allow someone to specify a default variable for all environments, but override the production one, for example.

Links

• gitlab-ce#17986
• gitlab-ce#17633

Documentation blurb

Project variables are often the right solution to define values that are then used during deployments to specific environments. Since different environments (e.g.: staging and production) may require different values for the same task, such as the app name, it is important to create a direct binding between some variables and the related environment.

Scope variables are introduced to solve this issue, letting developers to define environments they will be applied to, even with wildcards like review/*. It is now easy to deploy to different environments with a minimal effort!