Use unknown value as a deployment tier when unspecified
What does this MR do and why?
As we try to magically figure out the deployment tier when net specified, we fall back to the other
value. At the same time, other
might be specified by the user as well. On dotcom around 16% of the "active" environments are marked as deployment_tier: other
.
We don't know whether these are actually marked as other by the user or by GitLab fallback.
This MR introduces a new value, unknown
to fall back to when no value is specified by the user.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
- Run the following pipeline:
prod:
script:
- echo "I'm production"
environment:
name: prod
other-env:
script:
- echo "I'm other"
environment:
name: other
deployment_tier: other
unknown-env:
script:
- echo "Booo"
environment:
name: unknown-env
- List the environments with the API
- Check that
prod
hastier: production
- thus figuring out well-known environments by name works - Check that
other
hastier:other
- thus setting other explicitly works - Check that
unknown-env
hastier: unknown
- thus this MR works