Meta: Merge train/release train/merge when master succeeds: run build on merged code before merging
- As a user when I merge a feature branch I want to make sure that master is still green after that.
- To be 100% sure it requires testing the merge of the feature with master, but master changes all the time.
- The busy repositories the time between merges is shorter than the build+test time.
- This calls for a release train, in which merges are queued in a sequence that is tested upfront.
How the feature works:
- Enable 'Merge when pipeline succeeds' https://docs.gitlab.com/ce/user/project/merge_requests/merge_when_pipeline_succeeds.html
- Enable 'Merge when master succeeds' or 'Release train', a new function
- All merge requests are tested as a feature branch on every commit, like you expect.
- If the feature branch is green the merge request has a button 'Merge when master succeeds' or 'Add as the 3th MR to the merge train'
- When you click 'Merge when master succeeds' on the first MR the tests start running for a merge with master
- If there is another MR where this button was already pushed and that is already running tests the second MR will enter a merge queue.
- Repeat for all other MR's, they are sequenced based on when the button was pressed and form a release train
- If a test fails on an MR it is no longer merged and all following MRs are tested without it
- Possible optimization: If a branch is the next one to be merged and it is already based on HEAD of master there is no need to run the tests again and it can just be merged when the button is pushed. Related: https://gitlab.com/gitlab-org/gitlab-ce/issues/27337
- Possible optimization: test subsequent MRs assuming the previous MRs succeed, but don't commit the merges until we know the previous MRs actually do succeed. If they don't, then throw away the optimistic pipeline and start over, based on a
master
without the failed MR. This is optional or future because if you have the compute capacity to run a bunch of things in parallel, why not just increase the parallelism of your pipeline so it runs faster in the first place?
Old description:
When I started working with gitlab's CI I expected to be able to set up a similar workflow as I see done on github, where a pull request triggers the CI to run the test suite on the merged code, ensuring that the resulting master after merge passes all tests. As far as I can see this is not possible in gitlab, and I think it would be a really nice option to have.
Judging from other issues posted around e.g. http://feedback.gitlab.com/forums/176466-general/suggestions/5683182-merge-requests-should-trigger-a-build-on-the-main, https://github.com/gitlabhq/gitlabhq/issues/7240, https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/270 this is a feature that a lot of people are looking for. I'm re-posting it here, since this seems to be the place to make feature requests.
If this is not a good workflow maybe some of you experienced gitlab CI developers could explain why, and how to best incorporate CI to test merges before actually merging them.
In our case, we don't want every fork have to configure a runner and to be tested on every commit, since the test suite requires computational resources running on an HPC cluster. And therefore a central runner that is triggered in the merging process would be the most convenient for us.
Customers
https://gitlab.my.salesforce.com/00161000002xBfL
Solution
Original product discovery issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/35261 (this was actually the original MVC issue, but was renamed to become the product discovery issue then closed.)
We will basically implement https://gitlab.com/gitlab-org/gitlab-ee/issues/895 but with some small adjustments and design updates.
Because the automatic merge and rebase retry we need to think of some abort flows and how to get that communicated to the user
- Abort when source branch advanced (will auto retry)
- Abort when source branch advanced too many times
5 times
(will not auto retry)
- Abort when source branch advanced too many times
- Abort when the pipeline fails (will not auto retry)
- Abort manually (will not auto retry)
- Prevent merge when too many concurrent merge requests competing to merge
Adjusted https://gitlab.com/gitlab-org/gitlab-ee/issues/895
- For the two merge request methods (
merge commit with semi-linear history
andfast-forward merge
), offer the ability to rebase and merge in a single action.
Note: For below, strikethrough indicates existing functionality that will be removed and bold indicates new functionality.
No pipeline exists (No GitLab CI set up)
- MR needs a rebase
- MR is non-rebaseable
Merge button, and an error after clicking the button- Access to source branch: Rebase locally button that shows instructions If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- No access to source branch: No buttons, only message to ask MR author to rebase locally
- MR is rebaseable
- Access to only source branch: Rebase button. If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- Access to source AND target branch: Merge and Rebase only buttons. Merge will auto-rebase+merge after pipeline succeeds. If Rebase only, after it succeeds, show Merge button.
- No access to source branch: No buttons, only message to ask MR author to rebase
- MR is non-rebaseable
- MR does not need a rebase
- Merge button
Pipeline running
- MR needs a rebase
- MR is non-rebaseable
Merge button, and an error after clicking the button- Access to source branch: Rebase locally button that shows instructions If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- No access to source branch: No buttons, only message to ask MR author to rebase locally
- MR is rebaseable
- Access to only source branch: Rebase button. If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- Access to source AND target branch: Merge (blue button) and Rebase only buttons. Merge will auto-rebase+merge after pipeline succeeds. If Rebase only, after it succeeds, show Merge (blue) and Merge when pipeline succeeds (orange) buttons.
- No access to source branch: No buttons, only message to ask MR author to rebase
- MR is non-rebaseable
- MR does not need a rebase
- Merge when pipeline succeeds button (blue)
- Merge button (orange) to merge immediately
Pipeline passed
- Same as No pipeline exists, above
Pipeline failed
- Will not auto retry
- Loses position in concurrent merge requests list trying to merge
Merge possible but too many concurrent merge requests
When rebase happens after pressing Rebase button or merge button that also does the rebasing
- widget
- If target branch advanced while in the process of rebasing again (Auto retries)
- widget
- When auto-retrying the rebase and spinning up a new pipeline the merge request should retain its position in the max 5 concurrent merge requests that are competing/racing to be merged
After rebase is done, and merge will happen as soon as Pipeline succeeds
- widget
- If target branch advanced while in the process of waiting to merge again (Auto retries)
- widget
- When auto-retrying the rebase and spinning up a new pipeline the merge request should retain its position in the max 5 concurrent merge requests that are competing/racing to be merged
Proposal with images
We will basically implement https://gitlab.com/gitlab-org/gitlab-ee/issues/895 but with some small adjustments and design updates.
Because the automatic merge and rebase retry we need to think of some abort flows and how to get that communicated to the user
- Abort when source branch advanced (will auto retry)
- Abort when source branch advanced too many times
5 times
(will not auto retry)
- Abort when source branch advanced too many times
- Abort when the pipeline fails (will not auto retry)
- Abort manually (will not auto retry)
- Prevent merge when too many concurrent merge requests competing to merge
Adjusted https://gitlab.com/gitlab-org/gitlab-ee/issues/895
- For the two merge request methods (
merge commit with semi-linear history
andfast-forward merge
), offer the ability to rebase and merge in a single action.
Note: For below, strikethrough indicates existing functionality that will be removed and bold indicates new functionality.
No pipeline exists (No GitLab CI set up)
- MR needs a rebase
- MR is non-rebaseable
Merge button, and an error after clicking the button- Access to source branch: Rebase locally button that shows instructions If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- No access to source branch: No buttons, only message to ask MR author to rebase locally
- MR is rebaseable
- Access to only source branch: Rebase button. If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- Access to source AND target branch: Merge and Rebase only buttons. Merge will auto-rebase+merge after pipeline succeeds. If Rebase only, after it succeeds, show Merge button.
- No access to source branch: No buttons, only message to ask MR author to rebase
- MR is non-rebaseable
- MR does not need a rebase
- Merge button
Pipeline running
- MR needs a rebase
- MR is non-rebaseable
Merge button, and an error after clicking the button- Access to source branch: Rebase locally button that shows instructions If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- No access to source branch: No buttons, only message to ask MR author to rebase locally
- MR is rebaseable
- Access to only source branch: Rebase button. If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- Access to source AND target branch: Merge (blue button) and Rebase only buttons. Merge will auto-rebase+merge after pipeline succeeds. If Rebase only, after it succeeds, show Merge (blue) and Merge when pipeline succeeds (orange) buttons.
- No access to source branch: No buttons, only message to ask MR author to rebase
- MR is non-rebaseable
- MR does not need a rebase
- Merge when pipeline succeeds button (blue)
- Merge button (orange) to merge immediately
Pipeline passed
- Same as No pipeline exists, above
Pipeline failed
- Will not auto retry
- Loses position in concurrent merge requests list trying to merge
Merge possible but too many concurrent merge requests
When rebase happens after pressing Rebase button or merge button that also does the rebasing
After rebase is done, and merge will happen as soon as Pipeline succeeds