[MDBF-105] Buildbot - Protected Branches Stage 2: autopush Created: 2020-06-16  Updated: 2023-11-30

Status: Open
Project: MariaDB Foundation Development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Vicențiu Ciorbaru Assignee: Vlad Bogolin
Resolution: Unresolved Votes: 0
Labels: buildbot
Remaining Estimate: 0d
Time Spent: 2.5d
Original Estimate: Not Specified

Issue Links:
PartOf
includes MDBF-109 Allow know failures Closed
is part of MDBF-45 Milestone 4: Protected branches Open
Relates
relates to MDBF-239 Customize status checks error message... Closed

 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.

 Comments   
Comment by Aleksey Midenkov [ 2021-04-01 ]

Also please take a look at this scheme:

1. John pushes X to  bb-10.3-john and checks his branch;
 
2. If it is ok, John pushes X to bb-10.3-stage;
 
3. Staging tests commit X in bb-10.3-stage:
 
       3a. if X ok, Staging pushes X to 10.3
 
       3b. if X failed, Staging drops X by rebase interactive and notifies John.
 
       3b'. if rebase interactrive fails Staging drops all commits after X and notifies all users whose commits were dropped: they should repush to bb-10.3-stage.
 
4. Main tests commit X in 10.3 , if it fails Main warns John to take an immediate action.
 
Actors: John (user), Staging (script), Main (script)

Comment by Aleksey Midenkov [ 2023-11-15 ]

Please add me as reviewer.

Generated at Thu Feb 08 03:35:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.