Behavior of the `milestone=any` filter for the Issues/MRs API change in a non back-compatible way
In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14586 (and the CE backport https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30613), the behavior for the milestone=Any
(or milestone=any
) API filter changed in a non-compatible way:
-
milestone=any
previously meant, issues/MRs with a milestone set -
milestone=any
now means, issues/MRs with or without a milestone set
The changelog is explicit ("For milestone filters, treat Any as No Filter (using null). Use -1 for No Milestone") but I'm surprised this behavior change wasn't caught during review nor automated testing.
Unfortunately, our triage automation is heavily relying on the Issues and MRs API, and that meant that @gitlab-bot applied the ~"Accepting merge requests" label to a lot of issues that don't have a milestone set, when our policy specifically targets issues with a milestone set (using the milestone=any
filter): https://gitlab.com/gitlab-org/quality/triage-ops/blob/dc24801d02ece6ca3abf5bb66a1632ac7cadc0f2/policies/label-accepting-merge-requests.yml#L16
For the records, with this behavior change, the policy above wrongly applied the ~"Accepting merge requests" to:
- https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/266413502 - 969 new issues in Runner project.
- https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/266413218 - 178 new issues in Gitaly project
- https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/266413355 - 33 new issues in GitLab QA project
- https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/266411793 - 1959 new issues in GitLab EE project.
Thanks @tmaczukin for the report!
/cc @cablett @smcgivern @gweaver @donaldcook @ashmckenzie @fjsanpedro @tigerwnz @gl-quality/eng-prod