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…
	
	Add table
		Add a link
		
	
		Reference in a new issue