Recently I completed initial work to enable commit-message-validator [0] to work with GitLab CI and GitLab merge requests. For those who are unaware, commit-message-validator is a linter tool designed to enforce Wikimedia's commit message guidelines. [1]
Soon after the feature was available, James Forrester added it to the test suite for abstract-wiki/wikifunctions/function-orchestrator [2] and found the first issue with the integration that I had not anticipated which he helpfully filed as T351253. [3]
In my estimation, the problem comes down to a question of whether we should prioritize reading commit message footer information nicely in GitLab's merge request interface where they are rendered as GitLab flavored markdown data or not. James' team has developed a convention of appending a backslash () after footer lines so that they render as individual lines when processed as markdown. This in turn leads to commit-message-validator rejecting some footers, most obviously "Bug: Tnnnn" footers, for having unwanted characters (the trailing " ").
Reasonable people can disagree on the "best" solution here, but I think it is likely that as a group we can reach consensus on what the proper behavior of the commit-message-validator tool should be. The most obvious options are: * Change nothing in commit-message-validator and suggest folks live with markdown rendering artifacts in GitLab merge request descriptions. * Change commit-message-validator to allow trailing " " data for commit message footers in GitLab repos. * Change commit-message-validator to allow users (typically a CI process) to configure allow/disallow of trailing " " data for commit message footers
Adding support for per-repo rules configuration would be a first for commit-message-validator. Until now it has provided a single opinionated ruleset based on interpretation of the commit message guidelines. [2]
Folks who actually care about this minutia (how git commit message footers look in and out of GitLab markdown rendering) are encouraged to think carefully and provide their opinions and supporting data on T351253. [3]
[0]: https://www.mediawiki.org/wiki/Commit-message-validator [1]: https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines [2]: https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orch... [3]: https://phabricator.wikimedia.org/T351253
Bryan
I'm quite disappointed in Gitlab for this. I briefly popped in to #gitlab to make sure that there was no recourse for this. Sadly, it seems that there is not.
On Tue Nov 28, 2023 at 4:46 PM PST, Bryan Davis wrote:
[...] In my estimation, the problem comes down to a question of whether we should prioritize reading commit message footer information nicely in GitLab's merge request interface where they are rendered as GitLab flavored markdown data or not. James' team has developed a convention of appending a backslash () after footer lines so that they render as individual lines when processed as markdown. This in turn leads to commit-message-validator rejecting some footers, most obviously "Bug: Tnnnn" footers, for having unwanted characters (the trailing " ").
Reasonable people can disagree on the "best" solution here, but I think it is likely that as a group we can reach consensus on what the proper behavior of the commit-message-validator tool should be. The most obvious options are:
- Change nothing in commit-message-validator and suggest folks live
with markdown rendering artifacts in GitLab merge request descriptions.
- Change commit-message-validator to allow trailing " " data for
commit message footers in GitLab repos.
- Change commit-message-validator to allow users (typically a CI
process) to configure allow/disallow of trailing " " data for commit message footers
IMO Markdown does not belong in a commit message. Markdown in commit messages is analogous to HTML in email.
A middleground could be to prefix the Bug: lines with hyphens so Gitlab would interpret them as a list. :/
NOTICE: completely personal opinion
I don't mind it being a bit scrambled on gitlab UI as long as the links work. I would not mind either seeing the trailing `` on the git commits (or any other markdown).
I would try to avoid complexity though and not implement per-team/repo setting unless strictly necessary. And probably try to put that effort on improving the developer experience when using that validation tool (creating an auto-formatter, or prompting the user for bugs/missing fields, etc.).
On Wed, Nov 29, 2023 at 11:08 PM Brett Cornwall bcornwall@wikimedia.org wrote:
I'm quite disappointed in Gitlab for this. I briefly popped in to #gitlab to make sure that there was no recourse for this. Sadly, it seems that there is not.
On Tue Nov 28, 2023 at 4:46 PM PST, Bryan Davis wrote:
[...] In my estimation, the problem comes down to a question of whether we should prioritize reading commit message footer information nicely in GitLab's merge request interface where they are rendered as GitLab flavored markdown data or not. James' team has developed a convention of appending a backslash () after footer lines so that they render as individual lines when processed as markdown. This in turn leads to commit-message-validator rejecting some footers, most obviously "Bug: Tnnnn" footers, for having unwanted characters (the trailing " ").
Reasonable people can disagree on the "best" solution here, but I think it is likely that as a group we can reach consensus on what the proper behavior of the commit-message-validator tool should be. The most obvious options are:
- Change nothing in commit-message-validator and suggest folks live
with markdown rendering artifacts in GitLab merge request descriptions.
- Change commit-message-validator to allow trailing " " data for
commit message footers in GitLab repos.
- Change commit-message-validator to allow users (typically a CI
process) to configure allow/disallow of trailing " " data for commit message footers
IMO Markdown does not belong in a commit message. Markdown in commit messages is analogous to HTML in email.
A middleground could be to prefix the Bug: lines with hyphens so Gitlab would interpret them as a list. :/ _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
wikitech-l@lists.wikimedia.org