Introduce a mode where notes updates are persisted immediately or in a transactioned manner #1397
Comments
|
Note that pushing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the near future, I would like to move towards a GitHub Actions-based variant of GitGitGadget (see #609 for more details).
There is one obscure challenge this brings with it: currently, GitGitGadget only ever runs one Azure Pipeline at a time, which is ensured by having a single agent pool service those Pipelines, and that agent pool contains a single VM.
This is necessary because GitGitGadget's functionality has a state, and that state is persisted in
refs/notes/gitgitgadget. That state is typically fetched at the beginning of the Pipeline run, updated viagit notes --ref=gitgitgadget add [...]calls, and pushed at the end of the run.This same single-VM strategy won't work with GitHub Actions because self-hosted runners are a security risk on public GitHub repositories.
The best strategy to deal with
refs/notes/gitgitgadgetupdates which I can think of is to move to a transaction pattern, where a failed push will force-fetch the notes ref, then try again to modify the state and push again. This will allow concurrent jobs to modifyrefs/notes/gitgitgadget"at the same time" (for all practical purposes, at least, that's an accurate-enough mental model of this strategy).I imagine the implementation to move https://github.com/gitgitgadget/gitgitgadget/blob/main/lib/git-notes.ts to a transaction-like interface where a number of operations are stored (and even applied to the notes ref), and upon a
commit()try to push, if it fails enter that retry loop with incrementing delays.This will change the interface of the
GitNotesclass noticeably, e.g. by makinggetString()/setString()private and it will have to pull the functionality to update theIGitGitGadgetOptionsinstance into a transactioned model rather than letting the caller do the "read it, deserialize it, modify it, serialize it, overwrite it" dance.EDIT: An alternative strategy would be to enclose each and every call to
GitNotesthat updates a note in a retry loop. This seems a bit less elegant to me, though.The text was updated successfully, but these errors were encountered: