Merge CE commit into EE immediately
We currently have ee_compat_check which checks whether the MR in CE can be merged into EE.
We need to create a way of not only checking the compatibility, but also creating the merge right away. The job name suggestion is: ee_commit_merge
.
We have two options:
- Redo compat check to automatically create a MR and keep syncing the MRs as development continues
- Create a MR to EE as soon as the MR lands in master
Impact
In https://gitlab.com/gitlab-org/release/framework/issues/49#note_114614619 we analysed the time it takes to close the periodic CE to EE merge requests. Here we found that the total time these MRs remain open per month varies from several days to almost two weeks. We also found that the average time to close these MRs is around 7 hours, with the occasional peak up to several days.
In https://gitlab.com/gitlab-org/release/framework/issues/49#note_116565389 we looked at how often conflicts might happen on master
, limiting us to the latest 50 commits from CE master. Out of the 50 commits looked at, 19 produced a conflict (38%). We may be able to reduce this number by improving the EE compatibility check that runs on merge requests, for example by re-running it before merging, taking into account the latest master
changes.
Proposed plan (as of November 12, 2018)
Every time we push to CE master
, we try to merge the commit into EE master using CI. CI will set up a branch from EE master
, then merge the CE commit into it. If this succeeds, we push straight into EE master. If this fails, we need to find the last CE commit that does merge into EE master
, then revert everything up until that commit. The exact revert procedure is still up for debate, but it would come down to roughly the following steps:
- Find the commits to revert
- For every commit to revert:
- Revert the commit in
master
, using the GitLab revert API. Make sure the commit message contains some sort of tag (e.g.[no revert]
) so we don't end up reverting the revert just because the build fails (which could happen when there are more commits pending a revert). - Create a new branch from master
- Revert the revert commit on this branch (so basically
git revert (git revert ....)
. - Create an MR for this branch. This is important, because having a single MR for all reverted commits will make it frustrating to reinstate your changes, as you now need to wait for others before the MR can be merged.
- Assign the MR to the commit author, or a member of the ~Delivery team if no author could be found. It is then up to them to figure out who to assign the MR to.
- Add the appropriate labels so we can track how often this happens, how fast the problems are resolved, etc.
- Revert the commit in
Things to take into account
-
VERSION
in EE will conflict on stable branches, because EE uses a-ee
tag. This means we need a custom merge driver forVERSION
files, otherwise we'll revert stable branch commits that change this file.