Skip to content

Expand Remote Development triage rules

David O'Regan requested to merge master-patch-59e5 into master

What does this MR do and why?

As per https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#automations, we want to expand the rule set for the Category:Remote Development triage automation where possible. This MR aims to add as many of the listed automation as is currently possible building on https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage

Goal: To ensure every issue in the category is assigned to an epic

Automation:

Issues in ~"Category:Remote Development" but no epic assigned should get a warning comment (TODO: implement)
Goal: To ensure category issues show up on the Iteration Planning board

Automation:

Issues in ~"Category:Remote Development" but no ~rd-workflow label should be added to ~rd-workflow::unprioritized (Currently implemented as Rule index 0)
Goal: To avoid premature assignment of specific milestones before an issue has gone through IPM, to avoid getting this warning: https://gitlab.com/gitlab-org/gitlab/-/issues/411933#note_1419147845

Automation:

Issues with a specific milestone but not in ~rd-workflow::prioritized should have the milestone automatically set back to %"Next 1-3 releases" (TODO: implement)
Issues with a specific milestone but no weight should have the milestone automatically set back to %"Next 1-3 releases" (TODO: implement)
Issues with a specific milestone but no iteration should have the milestone automatically set back to %"Next 1-3 releases" (TODO: implement)
Goal: To ensure prioritized issues are in the correct state

Automation:

Issues in ~rd-workflow::prioritized but not assigned to the current Iteration of the Iteration Cadence should automatically get assigned to the Current Iteration (TODO: implement)
Issues in ~rd-workflow::prioritized and with weight assigned but no assignee should get a warning comment (TODO: implement)
Issues in ~rd-workflow::prioritized and specific milestone but no weight assigned should get a warning comment (TODO: implement)
Goal: Syncing Remote Development workflow and GitLab workflow labels

Automation:

Issues in ~rd-workflow::unprioritized but with no GitLab workflow label should have ~"workflow::refinement" assigned (TODO: implement)
Unstarted issues in ~rd-workflow::prioritized but with ~"workflow::refinement" assigned should get ~"workflow::ready for development" assigned (TODO: implement)
Can we assume that other subsequent workflow states are already handled by standard triage rules? If so, confirm and list/link them (TODO: implement)
Goal: To ensure issues and MRs are 1-1

Automation:

Every MR in ~"Category:Remote Development" must have the first line of the description matching: Issue: <issue link>\n\n. See https://docs.gitlab.com/ee/topics/gitlab_flow.html#linking-and-closing-issues-from-merge-requests (TODO: implement)
Every Issue in ~"Category:Remote Development" must have the first line of the description matching: "MR: \n\n" or "MR: No associated MR\n\n". See https://docs.gitlab.com/ee/topics/gitlab_flow.html#linking-and-closing-issues-from-merge-requests (TODO: implement)

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

Edited by David O'Regan

Merge request reports