Skip to content

Use unknown value as a deployment tier when unspecified

Viktor Nagy (GitLab) requested to merge nagyv-gitlab-master-patch-13543 into master

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.

  1. 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
  1. List the environments with the API
  2. Check that prod has tier: production - thus figuring out well-known environments by name works
  3. Check that other has tier:other - thus setting other explicitly works
  4. Check that unknown-env has tier: unknown - thus this MR works
Edited by Hunter Stewart

Merge request reports