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-orchestrator/-/commit/dd9b43212fbc884c78e2729c78fac04d6eb6ad87
[3]: https://phabricator.wikimedia.org/T351253
Bryan
--
Bryan Davis Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis_(WMF)]] irc: bd808
_______________________________________________
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/
[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-orchestrator/-/commit/dd9b43212fbc884c78e2729c78fac04d6eb6ad87
[3]: https://phabricator.wikimedia.org/T351253
Bryan
--
Bryan Davis Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis_(WMF)]] irc: bd808
_______________________________________________
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/
