04a24a0c60
This revamps code quite a bit. Series handling has been moved into the gerrit client, it also handles caching. The Runner logic itself has been greatly simplified. The runner logic has been moved into the runner.go, submitqueue.go is gone. The "per-run result object" concept has been dropped - we instead just use annotated logs. Also, we switched to apex/log |
||
|---|---|---|
| .buildkite | ||
| frontend | ||
| gerrit | ||
| public | ||
| submitqueue | ||
| .envrc | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| README.md | ||
| shell.nix | ||
gerrit-queue
This daemon automatically rebases and submits changesets from a Gerrit instance, ensuring they still pass CI.
In a usual gerrit setup with a linear master history, different developers
await CI feedback on a rebased changeset, then one clicks submit, and
effectively makes everybody else rebase again. gerrit-queue is meant to
remove these races to master. Developers can add a specific tag to a changeset,
and if all preconditions are met (passing CI and passing Code Review),
gerrit-queue takes care of rebasing and submitting it to master.
How it works
Gerrit only knows about Changesets (and some relations to other changesets), but usually developers think in terms of multiple changesets.
The Fetching Phase
gerrit-queue fetches all changesets from gerrit, and tries to identify these
chains of changesets. We call them Series. All changesets need to have strict
parent/child relationships to be detected.
Series are ordered by the number of changesets in them. This ensures longer series are merged faster, and less rebases are triggered. In the future, this might be extended to other metrics.
The Submit Phase
We loop over all series. If all changesets of a given series pass the required preconditions (passing CI, passing Code Review, autosubmit Tag) and it's rebased on top of the current destination branch's HEAD, it can be submitted.
The current serie is removed from the list of series, and we update our HEAD to the commit ID of the last commit in the submitted series.
The Rebase Phase
We loop over all remaining series. The first one matching the required preconditions is rebased on top of the (advanced HEAD) (and if this fails, we skip and keep trying with the next Series one after another).
These three phases are designed to be stateless, and currently triggered once per run. This is supposed to be moved to a more reactive model, so that the submit phase is triggered by Webhooks for CI feedback, and we don't rebase too often
Compile and Run
go generate
GERRIT_PASSWORD=mypassword go run main.go --url https://gerrit.mydomain.com --username myuser --project myproject