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]