This is required to solve our state of database, where depchecks have
multiple jobs with the same uuid, and in the resultsdb 2.0 the uuid is
an unique identifier of the group.
This is done by merging the results of each "duplicate" job to the first
one with that specified uuid, and deleting the other (now result-less)
jobs.
Details
Details
Tested the migration locally on engineered data
Diff Detail
Diff Detail
- Repository
- rRSDB resultsdb
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
I'd say that dev is more-or-less sacrifice-able. I think it would behoove us to make backups of the DB before doing things which could bork data so that we can have more than one try if needed, though.