Hi,
Cyril Brulebois (2020-06-01):
> I'll share some more, spotted during the last few days and while
> finalizing the contents of 4.7 thanks to anonym's help:
>
> * It would be nice if we could close tickets from a commit message,
> e.g. when merging a branch, as we used to be able to with “Closes:
> #N”. It might not be important on the long run if we standardize for
> always using a MR, but I'd be happy not to have to remember closing
> tickets manually while we deal with the many topic branches we have.
> Various attempts seems to have failed (d4ffd3ebc60c, 7f5361119001).
>
> * One might think “just use a MR” as a reply to the aforementioned
> point but right now, I'm not convinced… The commit message doesn't
> mention bug(s) getting fixed, doesn't contain a direct link to the
> MR, and just a reference the interested reader needs to resolve on
> their own. Of course, for single-bug topic branches, the name might
> be sufficient. For longer-lived branches (overlayfs, secure boot,
> etc.), I'm pretty sure all bugs won't be mentioned in the branch's
> name.
I hear you and I personally find these problems annoying as well.
To sum up what I see:
- Regarding "mention all relevant issues in the commit message", one
workaround is to do what we would have done pre-GitLab, that is:
manually edit the merge commit message to include the desired info
(be it via the GitLab web UI or by merging locally).
But of course it would be better to automate this!
- We do have a regression wrt. closing issues while merging,
compared to Redmine.
I've looked deeper into this topic a couple days ago after our
conversation on XMPP, and here's what I found:
1. The "close referenced issues when merging" behavior only works
for the main branch, i.e. currently "master" in our case.
One lead I'd like to investigate is making "devel" our main branch
(and in passing, perhaps rename "master" to "website"). I did not
verify what would happen under that config in the most common
scenarios, that is when the target branch of the MR is stable, and
then one merges stable manually into devel.
2. When merging a MR into the main branch, the merge commit message
generated by GitLab does mention the issues being closed.
Example:
commit 12fdeb9995503b0263134f8284f8aeebc284b7b0
Merge: bc4dcec41b 015ef0767f
Author: intrigeri <intrigeri@???>
Date: Sat May 30 06:02:49 2020 +0000
Merge branch 'feature/17133-update-signing-key' into 'master'
Bump our signing key's expiration date
Closes #17133
See merge request tails/tails!17
But that's not the case when merging into a non-main target branch,
and I've found no way to customize this (it seems fully hard-coded
in GitLab's code). So for now, manually editing the commit message
(i.e. like we did with Redmine) is the only way to go.
All this seems to boil down to GitLab being optimized for
1-main-branch workflows. I'd like to spend some time thinking about
how we could adjust our workflow to fit better. I'll focus on the
regression (closing issues via merge commits) to start with.
Cheers!
