Resolve "Duplicate rows with the same tag name in Release"
What does this MR do and why?
Removes any existing releases with duplicate tags in a project, keeping the latest release (i.e. released_at)
Screenshots or screen recordings
The query takes about 3 seconds, which is within the tolerance for post-release migrations
https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/7831/commands/27959
Unfortunately I see no way to undo this migration once it is applied.
User Impact
Since creation of these duplicate releases are blocked at the service level there aren't many of these releases. Only the most recent of the duplicate releases would be available after this migration.
Also according to @shinya.maeda in the comments below
However, since invalid rows are very rare (we do NOT allow users to create such records in the service class) and they can't be operated correctly (e.g. it's fetched randomly), it's highly unlikely that users face issues.
Currently in production there seem to be 591 of these releases that would be removed
###Migration Output
== 20211217192453 RemoveDuplicateProjectTagReleases: migrating ================
== 20211217192453 RemoveDuplicateProjectTagReleases: migrated (0.0023s) =======How to set up and validate locally
To test the migration
- Open
rails console - Note how many releases there are with
Release.count - Create some old duplicate releases with
Release.last.dup.update_attribute(:released_at, 5.years.ago) - Note how many new releases there are
- Run the migration
- Release count should be back to original number (or lower if you had existing duplicates)
To test the validation
- Open
rails console - Try to save a duplicate
Release.last.dup.save! - See that it fails
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.
Related to #31869 (closed)