Re: On pull request workflows for the GNU toolchain

Joseph Myers via Gdb
2024-09-20T20:42:49Z

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