Expand Remote Development triage rules
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
-
If adding environment variables for reactive processors, update config/triage-web.yaml
and.gitlab/ci/triage-web.yml
-
(If applicable) Add documentation to the handbook pages for Triage Operations => - (If applicable) Identify the affected groups and how to communicate to them:
-
/cc @ person_or_group
=> -
Relevant Slack channels => -
Engineering week-in-review
-