Re: On pull request workflows for the GNU toolchain

[Joseph Myers via Gdb <gdb@sourceware.org>]

On Fri, 20 Sep 2024, Carlos O'Donell via Gcc wrote:

> > (e) All existing pre-commit checks from hooks should be kept in some
> > form, to maintain existing invariants on both tree and commit contents
> > (some hook checks make sure that commits don't have commit messages
> > that would cause other automated processes to fall over later, for
> > example).
> 
> These could all move to pre-commit CI checks that block merging.

Checks are supposed to apply to direct pushes as well as to merging 
through the PR system.  (Direct pushes should I hope end up being rare on 
mainline, not necessarily rare on other branches.  Some invariants of 
commit history should apply to all commits on all refs, e.g. that no-one 
accidentally copies an old GCC commit message in a way that confuses 
tooling searching for From-SVN: lines.  On mainline, we might eventually 
want an *additional* check on direct pushes, e.g. that they have a 
Reason-for-direct-push: line that explains why the commit can't go through 
the PR system.)

Obviously this does not assert what technology should be used to implement 
such checks on permitted ref updates in the repository (though hopefully 
as little code as possible is executed in the repository context, as much 
as possible in some separate isolated context).  And arranging the 
implementation so as much code as possible can be used both when checking 
the final ref update, and in CI to check a PR that would result in such a 
ref update if accepted, is desirable (just as e.g. GCC shares code between 
the cron job that does ChangeLog updates, and the hook that checks if 
commits have properly formatted ChangeLog entries - though there are 
unfortunately still some cases that only result in the cron job falling 
over, not in the commits being rejected at push time).

-- 
Joseph S. Myers
josmyers@redhat.com