Skip to content

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:

Thanks @tmaczukin for the report!

/cc @cablett @smcgivern @gweaver @donaldcook @ashmckenzie @fjsanpedro @tigerwnz @gl-quality/eng-prod