On this issue we are only implementing the code for a background migration that will use the epic_issues table to backfill the work_item_parent_links table.
This migration will be scheduled in the future when the initial backfilling of all epics is complete
If you are unsure about the correct group, please do not leave the issue without a group label, and refer to
GitLab's shared responsibility functionality guidelines
for more information on how to triage this kind of issue.
If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.
This issue was automatically tagged with the label groupdatabase by TanukiStan, a machine learning classification model, with a probability of 0.99.
If this label is incorrect, please tag this issue with the correct group label as well as automation:ml wrong to help TanukiStan learn from its mistakes.
Authors who do not have permission to update labels can use the @gitlab-bot label ~"group::<correct group name>" command, or leave the issue to be triaged by group leaders initially assigned by TanukiStan.
This message was generated automatically.
You're welcome to improve it.
@acroitor quick question about this one. I think the initial sync mechanism didn't sync this relationship, correct? So my guess is that we have some epic records that do have an issue associated (because of the initial attribute sync), but that might not have the parent link relationship created? Just wondering if I should skip records where epics.issue_id IS NOT NULL on the batch migration or not.
Alexandru Croitorchanged title from Implement work_item_parent_links backfilling migration to Implement work_item_parent_links backfilling migration for epic_issues table
changed title from Implement work_item_parent_links backfilling migration to Implement work_item_parent_links backfilling migration for epic_issues table