Skip to content

tracking-issue: Supported nested tracking issues in different milestones

Administrator requested to merge ef/tracking-issue-nested-milestones into main

Created by: efritz

Closes https://github.com/sourcegraph/sourcegraph/issues/14177.

Context

After introducing nesting of tracking issues I neglected to think about tracking issues that can span different milestones. When I added the feature I was using smaller milestones to test, which happened to have the same labels and the same milestone set. It's perfectly valid to have an un-milestoned tracking issue, or even a milestoned tracking issue that contains items milestoned earlier/later, but this isn't well supported (the items will show up, but the tracking issues won't).

What we'll change

We'll need to additionally bring back the tracking issues from the GitHub API despite what it's selected milestone is. We'll then need to ensure that each assignee's workload will reflect only the correctly visible issues (no RFCs with no work items, etc).

How we changed it

We query labels+"tracking" as additional issue records when looking at milestone tracking issues. Then, when rendering, we add checks to determine if an item from the newly expanded set of issues and pull requests should be rendered for the given assignee. This is implemented as a milestone/assignee comparison or, in the case of tracking issues, a bounded recursive search of the issues they track.

Note: This is currently running, so if you like the way the current tracking issues look, 👍 !

Another note: I see that some @sourcegraph/cloud RFCs are not labeled with the team. Be aware that the labels still behave as "AND", so these issues will not show up. All issues on a tracking issue must have the same labels as the parent tracking issue. I wanted to see if such RFC tracking issues were expected to show up (e.g. https://github.com/sourcegraph/sourcegraph/issues/14166 vs https://github.com/sourcegraph/sourcegraph/issues/14163).

Merge request reports