No description
Find a file
Florian Klink 241ec393ac main: actually multiply triggerInterval by time.Second, not time.Minute
Otherwise, we'd wait a little bit too long ;-)
2019-12-03 10:58:39 +01:00
.buildkite WIP: build binary and container 2019-11-22 19:51:16 +01:00
frontend add rotatingloghandler which removes older log entries 2019-12-02 12:03:46 +01:00
gerrit changeset: fetch SUBMITTABLE and add field to struct 2019-12-03 10:16:32 +01:00
misc add rotatingloghandler which removes older log entries 2019-12-02 12:03:46 +01:00
public Use Runner 2019-12-02 10:00:32 +01:00
submitqueue runner: use submittable field 2019-12-03 10:20:02 +01:00
.envrc .envrc: enable go modules 2019-11-25 17:48:08 +01:00
.gitignore gitignore /gerrit-queue 2019-11-21 19:00:54 +01:00
go.mod Use Runner 2019-12-02 10:00:32 +01:00
go.sum add rotatingloghandler which removes older log entries 2019-12-02 12:03:46 +01:00
LICENSE Create LICENSE 2019-11-18 17:48:24 +01:00
main.go main: actually multiply triggerInterval by time.Second, not time.Minute 2019-12-03 10:58:39 +01:00
README.md add README.md 2019-11-18 19:26:51 +01:00
shell.nix WIP: build binary and container 2019-11-22 19:51:16 +01:00

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