Allow using Gitlab-CI scoped environment variables without creating an environment
Problem to solve
Using the Gitlab-CI environment
keyword in a stage always creates a specific environment
and is tracked as if a deployment has occured. This is not always the case, especially if you want to leverage cluster scoped variables without deploying.
For example if you are deploying to multiple clusters and use a Kubernetes templating tool with scoped environment variables your CI might look like this:
Create Cluster-01 Templates:
image: my-template-tool
script:
- create_deployment_templates ${MY_CLUSTER_SCOPED_VARIABLE} > cluster-01/deployment.yml
environment:
name: cluster-01/templates
artifacts:
paths:
- cluster-01/deployment.yml
Deploy to Cluster-01:
script:
- kubectl apply -f cluster-01/deployment.yml
environment:
name: cluster-01/deployment
only:
- master
You would like your templates to be created on every build to ensure that they are valid (and to possibly include some linting), but only deployed on master. Right now, this means that a new 'environment' cluster-01/templates
will be created and 'deployments' to this tracked, which adds noise as you are not deploying anything. This might also interact with plugins that assume that each 'environment' is an actual release.
On top of this, each MR gets a very confusing notification saying that something was deployed, which frightens users:
My suggestion is to decouple the use of scoped environment variables from creating an 'envirionment' and tracking a release. There are use cases where you want scoped environment variables but are not releasing anything.
Intended users
Proposal
Perhaps adding a tracked
boolean to the environment
section?
Create Cluster-01 Templates:
...
environment:
name: cluster-01/templates
tracked: false