1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
# Automatic CE->EE merge
Whenever a commit is pushed to the CE `master` branch, it is automatically
merged into the EE `master` branch. If the commit produces any conflicts, it is
instead reverted from CE `master`. When this happens, a merge request will be
set up automatically that can be used to reinstate the changes. This merge
request will be assigned to the author of the conflicting commit, or the merge
request author if the commit author could not be associated with a GitLab user.
If no author could be found, the merge request is assigned to a random member of
the Delivery team. It is then up to this team member to figure out who to assign
the merge request to.
Because some commits can not be reverted if new commits depend on them, we also
run a job periodically that processes a range of commits and tries to merge or
revert them. This should ensure that all commits are either merged into EE
`master`, or reverted, instead of just being left behind in CE.
## Always merge EE merge requests before their CE counterparts
**In order to avoid conflicts in the CE->EE merge, you should always merge the
EE version of your CE merge request first, if present.**
The rationale for this is that as CE->EE merges are done automatically, it can
happen that:
1. A CE merge request that needs EE-specific changes is merged.
1. The automatic CE->EE merge happens.
1. Conflicts due to the CE merge request occur since its EE merge request isn't
merged yet.
1. The CE changes are reverted.
## Avoiding CE->EE merge conflicts beforehand
To avoid the conflicts beforehand, check out the
[Guidelines for implementing Enterprise Edition features](ee_features.md).
In any case, the CI `ee_compat_check` job will tell you if you need to open an
EE version of your CE merge request.
### Conflicts detection in CE merge requests
For each commit (except on `master`), the `ee_compat_check` CI job tries to
detect if the current branch's changes will conflict during the CE->EE merge.
The job reports what files are conflicting and how to set up a merge request
against EE.
## How to reinstate changes
When a commit is reverted, the corresponding merge request to reinstate the
changes will include all the details necessary to ensure the changes make it
back into CE and EE. However, you still need to manually set up an EE merge
request that resolves the conflicts.
Each merge request used to reinstate changes will have the "reverted" label
applied. Please do not remove this label, as it will be used to determine how
many times commits are reverted and how long it takes to reinstate the changes.
An example merge request can be found in [CE merge request
23280](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23280).
## How it works
The automatic merging is performed using a project called [Merge
Train](https://gitlab.com/gitlab-org/merge-train/). For every commit to merge or
revert, we generate patches using `git format-patch` which we then try to apply
using `git am --3way`. If this succeeds we push the changes to EE, if this fails
we decide what to do based on the failure reason:
1. If the patch could not be applied because it was already applied, we just
skip it.
1. If the patch caused conflicts, we revert the source commits.
Commits are reverted in reverse order, ensuring that if commit B depends on A,
and both conflict, we first revert B followed by reverting A.
## FAQ
### Why?
We want to work towards being able to deploy continuously, but this requires
that `master` is always stable and has all the changes we need. If CE `master`
can not be merged into EE `master` due to merge conflicts, this prevents _any_
change from CE making its way into EE. Since GitLab.com runs on EE, this
effectively prevents us from deploying changes.
Past experiences and data have shown that periodic CE to EE merge requests do
not scale, and often take a very long time to complete. For example, [in this
comment](https://gitlab.com/gitlab-org/release/framework/issues/49#note_114614619)
we determined that the average time to close an upstream merge request is around
5 hours, with peaks up to several days. Periodic merge requests are also
frustrating to work with, because they often include many changes unrelated to
your own changes.
Automatically merging or reverting commits allows us to keep merging changes
from CE into EE, as we never have to wait hours for somebody to resolve a set of
merge conflicts.
### Does the CE to EE merge take into account merge commits?
No. When merging CE changes into EE, merge commits are ignored.
### My changes are reverted, but I set up an EE MR to resolve conflicts
Most likely the automatic merge job ran before the EE merge request was merged.
If this keeps happening, consider reporting a bug in the [Merge Train issue
tracker](https://gitlab.com/gitlab-org/merge-train/issues).
### My changes keep getting reverted, and this is really annoying!
This is understandable, but the solution to this is fairly straightforward:
simply set up an EE merge request for every CE merge request, and resolve your
conflicts before the changes are reverted.
### Will we allow certain people to still merge changes, even if they conflict?
No.
### Some files I work with often conflict, how can I best deal with this?
If you find you keep running into merge conflicts, consider refactoring the file
so that the EE specific changes are not intertwined with CE code. For Ruby code
you can do this by moving the EE code to a separate module, which can then be
injected into the appropriate classes or modules. See [Guidelines for
implementing Enterprise Edition features](ee_features.md) for more information.
### Will changelog entries be reverted automatically?
Only if the changelog was added in the commit that was reverted. If a changelog
entry was added in a separate commit, it is possible for it to be left behind.
Since changelog entries are related to the changes in question, there is no real
reason to commit the changelog separately, and as such this should not be a big
problem.
|
