add README.md
This commit is contained in:
parent
28bc242178
commit
43f8205e85
1 changed files with 49 additions and 0 deletions
49
README.md
Normal file
49
README.md
Normal file
|
@ -0,0 +1,49 @@
|
|||
# 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
|
||||
```
|
Loading…
Reference in a new issue