Skip to content

Tag Removal Check

Adding a new check

This checks tests for if a customer may be impacted by gitlab-org/gitlab#524402 (closed)

UPDATE: After testing this should work both pre and post occurence will edit.

Verification steps for review

  1. Have runner tags on an instance on 17.5.0
  2. upgrade to 17.8.0
  3. Open a SQL session gitlab-psql
  4. execute select exists(select * from ci_runner_taggings) as has_row;
  5. This should return f
  6. Run the playbook that includes this check: there should be a message attribute for this check -- indicating that the check did not pass.
  7. run
gitlab-rake db:migrate:down VERSION=20241219100359
gitlab-rake db:migrate:up VERSION=20241219100359
  1. Run the playbook that includes this check: there should be no message attribute for this check -- indicating that the check did pass.

Author checklist

  • After opening the MR:
    • Set it to the current milestone
    • Ask the Maintainer from the Reviewer roulette suggestion for review

Reviewer checklist

  • I followed the verification steps and confirm the functionality of the new check
    • I executed the check as presented in this MR by running the generated playbook with spot
    • In case of unexpected/odd behavior here, verify the generated playbook to account for potential YAML parsing issues
  • This check does only perform read operations
  • This check does not output more than necessary on stdout for the check to function
  • The message explains what it means when this check does not pass
  • The workaround_url provides actionable information/steps for affected users
    • Consider if a Knowledge Base article should exist to serve as the ideal workaround URL
  • This check is not using the Rails console/runner, or has Maintainer approval for doing so
  • If this is a breaking change check:
    • It has the corresponding xx_breaking_changes tag (xx being the major release version for the change)
    • The workaround_url goes to the entry on the https://docs.gitlab.com/update/deprecations/ page
    • The ref_url goes to the deprecation issue linked from that entry
    • The title is the same as that entry
    • The version_started is equal to the announcement_milestone of the deprecation
    • The version_fixed is equal to the removal_milestone of the deprecation
Edited by Jessie Lee

Merge request reports

Loading