50 lines
2.1 KiB
Markdown
50 lines
2.1 KiB
Markdown
|
# 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
|
||
|
|
```sh
|
||
|
|
go generate
|
||
|
|
GERRIT_PASSWORD=mypassword go run main.go --url https://gerrit.mydomain.com --username myuser --project myproject
|
||
|
|
```
|