GitLab closes issues that shouldn't close based on the default closing pattern

Summary

When using the https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically feature, GitLab seems to close issues that don't match the default regex. Is EF using a custom regex for matching issues in git log?

Steps to reproduce

eclipse/oniro-core/oniro!221 (merged) has a set of commits mentioning various issues for automatic closing. Example:

[...]
Fixes: https://gitlab.eclipse.org/eclipse/oniro-core/oniro/-/issues/723
[...]
Fixes: https://gitlab.eclipse.org/eclipse/oniro-core/oniro/-/issues/724
[...]

It also references another issue which is marked for closing too:

[...]
To help Oniro with
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1565, EF created
[...]

The default regex \b((?:[Cc]los(?:e[sd]?|ing)|\b[Ff]ix(?:e[sd]|ing)?|\b[Rr]esolv(?:e[sd]?|ing)|\b[Ii]mplement(?:s|ed|ing)?)(:?) +(?:(?:issues? +)?%{issue_ref}(?:(?: *,? +and +| *,? *)?)|([A-Z][A-Z0-9_]+-\d+))+) (see https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically) should not match that mention as it lacks the needed keywords. Even so, the MR mentions under the Merge button that it will close it too:

Fast-forward merge without a merge commit
Closes issues #723, #724, and eclipsefdn/helpdesk#1565

There is a way to customise this matching pattern: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#customize-the-issue-closing-pattern and besides this being a bug the only explanation that I have is that EF sets that to a custom value that matches any reference.

What is the current bug behaviour?

Merge requests marks mentioned issues that lack the required keywords up for closing.

What is the expected correct behaviour?

Merge should not mark mentioned issues that lack the required keywords up for closing.

Relevant logs and/or screenshots

See above.

added IT-prioritylow IT-severitylow statetodo team:releng labels

I'm not aware of any customization of the default closing pattern in gitlab.rb or gitlab.yml file of our installation (see https://docs.gitlab.com/ee/administration/issue_closing_pattern.html).

@droy can you confirm?

I've just merged the above-mentioned MR and it did close the issue that it shouldn't have been closed. See eclipse/oniro-core/oniro!221 (merged)

I've double-checked and we did not customize the default closing pattern. So I assume this is an upstream issue.

Please report it at https://gitlab.com/gitlab-org/gitlab/-/issues (if it has not been reported yet).

Thanks, @fgurr for looking into this. I'm not sure why we have closed it even if it is an upstream bug - we are still affected by it. Wouldn't it make sense to check with upstream first and close this when we either get a workaround, we upgrade to a fixed version or we clarify if this is a "current" behaviour?

So far, I have not found a bug that matches the issue you are describing.

I'd recommend that a bug is reported upstream and linked to this issue. I see not much value in keeping this issue open here, since there is not much we can do unless a workaround or fix is provided upstream.

OK. I will not be chasing this more. I was hoping that the IT team would see the benefit of having this fixed at the level of the EF infrastructure (and yes, we can definitely do more: report upstream, find a workaround, upgrade to a fixed version, etc.). I guess for now we will consider it a limitation of the EF infrastructure.

I can't follow the conclusion that this is a "limitation of the EF infrastructure". We did not change the default closing pattern regex or are aware of any configuration changes that could have affected the current behavior. So without evidence of the contrary I assume that it works as delivered in "GitLab Enterprise Edition 14.10.5-ee" and therefore constitutes an upstream issue.

Unfortunately we don't have the cycles to chase this down to the end.

I understood. Thanks for looking into it.

closed

removed statetodo label