Ensure environment tier is set when creating a deployment

What does this MR do and why?

In #357934 (closed) we started including the deployment tier of an environment in the allowed_agents API response, which allows users to define permissions per deployment tier.

All environments created since %13.10 have a tier set by default. However, any environments created in a version prior to this may not have been updated, and can (not always, see below) have an empty value for the tier. This causes an error to be raised in KAS, which assumes all environments have a tier.

To solve this, we re-save the environment (which triggers ActiveRecord callbacks to set the tier) whenever a job creates a deployment to an environment that doesn't yet have a tier set.

Doesn't this happen already when a a deployment is created?

Not always. There are two other processes that almost handle this for us:

• Deployments::UpdateEnvironmentService#renew_environment_tier: After a successful deployment, a worker (UpdateEnvironmentWorker) is triggered to sync any changes from the deployment to the environment. This doesn't solve our problem because:
  • It only runs on successful deployments. If the deployment fails, the worker is never triggered.
  • The tier is explicitly renewed from the deployment_tier keyword in the CI/CD template. If this isn't present in the template, no update is guaranteed.
  • The tier is implicitly set whenever an environment is saved (via ActiveRecord callbacks), however if there are no changes required (the environment doesn't change state, and its attributes are unchanged) the environment is not saved and no tier is set.
• Gitlab::Ci::Pipeline::Seed::Environment#to_resource: When persisting database records from the CI/CD template an environment is found/created using safe_find_or_create_by, and various attributes (including the tier) are set in the passed block. Again, this doesn't quite solve our problem:
  • It also uses the deployment_tier keyword in the CI/CD template.
  • The attributes assigned in the block are only persisted to the record if it is being created for the first time. An environment that already exists is fetched but has no attributes assigned and is never saved (so no callbacks fire).

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

gitlab-org/cluster-integration/gitlab-agent#332 (closed)