No description
Find a file
Florian Klink 266c27d1d0 foo
2019-11-25 17:42:48 +01:00
.buildkite WIP: build binary and container 2019-11-22 19:51:16 +01:00
frontend frontend: we already add hyperlinks 2019-11-25 17:36:39 +01:00
gerrit frontend: show submittable status and URL, add runner, revamp logging 2019-11-21 16:13:50 +01:00
public frontend: add menu, info box and log area 2019-11-22 16:41:19 +01:00
submitqueue foo 2019-11-25 17:42:48 +01:00
views initial import 2019-11-18 15:40:46 +01:00
.envrc use statik to bundle assets, add nix-shell/lorri .envrc 2019-11-18 16:29:57 +01:00
.gitignore gitignore /gerrit-queue 2019-11-21 19:00:54 +01:00
go.mod use statik to bundle assets, add nix-shell/lorri .envrc 2019-11-18 16:29:57 +01:00
go.sum use statik to bundle assets, add nix-shell/lorri .envrc 2019-11-18 16:29:57 +01:00
LICENSE Create LICENSE 2019-11-18 17:48:24 +01:00
main.go frontend: only pass runner to MakeFrontend, add Runner.GetSubmitQueue() 2019-11-25 17:35:11 +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