Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
The second stage for getting protected branches fully implemented involves automating the merges to master branch. The way this can work:
1. Developer X pushes to staging branch (say bb-10.5-stage-xxxx)
2. Buildbot begins testing.
3. Buildbot finishes tests, either red or green.
3.1. If tests are red, email developer and abort the push.
3.2. If they are green, buildbot attempts to fast forward the 10.5 branch to bb-10.5-stage-xxxx (git merge --ff-only bb-10.5-xxxxx). If successful, Commit is merged & pushed.
3.3. If tests are green, but it is not possible to fast forward the 10.5 branch (because someone else's changes were merged first), buildbot checks if there are any merge commits in the staging branch.[1]
3.3.1. If there are no merge commits, buildbot rebases automatically on top of recent 10.5 and goes to step 2, i.e. restarts testing.
3.3.1.1 If rebasing fails, email the developer and abort the push.
3.3.2. If there are merge commits, email developer and abort the push.
[1] There is a command git rebase --preserve-merges which may also be of use.
Also note:
A desirable feature is to be able to abort the autopush process in some way. For example deleting the branch could cause the final fast-forward step to be aborted.