GitLab Documentation

Automatic CE->EE merge

GitLab Community Edition is merged automatically every 3 hours into the Enterprise Edition (look for the CE Upstream merge requests).

This merge is done automatically in a scheduled pipeline. If a merge is already in progress, the job doesn't create a new one.

If you are pinged in a CE Upstream merge request to resolve a conflict, please resolve the conflict as soon as possible or ask someone else to do it!

Note: It's ok to resolve more conflicts than the one that you are asked to resolve. In that case, it's a good habit to ask for a double-check on your resolution by someone who is familiar with the code you touched.

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 every few hours, it can happen that:

  1. A CE merge request that needs EE-specific changes is merged
  2. The automatic CE->EE merge happens
  3. Conflicts due to the CE merge request occur since its EE merge request isn't merged yet
  4. The automatic merge bot will ping someone to resolve the conflict that are already resolved in the EE merge request that isn't merged yet

That's a waste of time, and that's why you should merge EE merge request before their CE counterpart.

Avoiding CE->EE merge conflicts beforehand

To avoid the conflicts beforehand, check out the Guidelines for implementing Enterprise Edition features.

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 setup a merge request against EE.

How the job works

  1. Generates the diff between your branch and current CE master
  2. Tries to apply it to current EE master
  3. If it applies cleanly, the job succeeds, otherwise...
  4. Detects a branch with the ee- prefix or -ee suffix in EE
  5. If it exists, generate the diff between this branch and current EE master
  6. Tries to apply it to current EE master
  7. If it applies cleanly, the job succeeds

In the case where the job fails, it means you should create a ee-<ce_branch> or <ce_branch>-ee branch, push it to EE and open a merge request against EE master. At this point if you retry the failing job in your CE merge request, it should now pass.

Notes:


Return to Development documentation


Leave a comment below if you have any feedback on the documentation. For support and other inquires, see getting help.