Re: Migration to CTI services should be an opportunity to reduce dependency on git hooks.

Joseph Myers <[email protected]> Mon, 8 Jul 2024 15:59:24 +0000 (UTC)
Newsgroups org.linuxfoundation.lists.cti-tac
Message-ID <[email protected]>
On Fri, 21 Jun 2024, Carlos O'Donell wrote:

> Then figure out deployment and cost e.g. small vm to run the isolated hook
> that returns a result, average timeout, and degraded result e.g. no bugzilla
> data.

There is a significant difference between pre-commit and post-commit 
actions from hooks.

Post-commit actions can be run in some completely different context (that 
receives some kind of append-only feed of ref changes in the repository), 
and a degraded result might be e.g. no commit mail or Bugzilla update.

Pre-commit actions ensure that some invariant of the commit history is 
maintained.  For example, in the GCC context, they ensure that the nightly 
ChangeLog updates won't fall over by verifying various commit properties 
(on master and release branches) required by those updates (imperfectly, 
because some things pass the checks at commit time but the updates still 
fail), and that new commits don't masquerade as ones converted from SVN so 
that tools expecting a single commit with a From-SVN: line referencing a 
given SVN commit, in order to map from SVN commits to git commits, don't 
fall over from a new commit quoting an old commit message in a ways that 
could confuse the commits.  (They also enforce rules on e.g. which refs 
are allowed non-fast-forward updates.)

The safe form of degraded result from a pre-commit check is to block the 
commit within a limited time if the check doesn't complete quickly (rather 
than running for hours).  One long-term way to avoid hooks for such 
pre-commit checks would be a system based on merge-requests where pushes 
to the main repository, or at least to branches on that repository needing 
greater levels of checks, are normally done only by a CI system that 
verifies the desired invariants before pushing, rather than directly by 
individual developers.  Although that sort of thing is more commonly done 
to ensure invariants of the state of the tree (i.e. that it builds and 
passes tests in some set of configurations), it certainly could be done to 
ensure invariants of the commit history instead.

-- 
Joseph S. Myers
[email protected]