diff --git a/PROCESS.md b/PROCESS.md index 758e773ae4d20bfc52a6593aa29e003d666e38f9..3fcf676b302eede95b4cd92d99cecf18114fa7e2 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -131,7 +131,7 @@ request, even if there are no conflicts. This is to reduce the size of the subsequent EE merge, as we often merge a lot to CE on the release date. For more information, see [Automatic CE->EE merge][automatic_ce_ee_merge] and -[Guidelines for implementing Enterprise Edition feature][ee_features]. +[Guidelines for implementing Enterprise Edition features][ee_features]. ### After the 7th diff --git a/doc/development/automatic_ce_ee_merge.md b/doc/development/automatic_ce_ee_merge.md index 1a2a968ef545c65e34ca83bac80b002eed049f33..9e59ddc8ccee918e3d508cd5446ff0c1f75c8d34 100644 --- a/doc/development/automatic_ce_ee_merge.md +++ b/doc/development/automatic_ce_ee_merge.md @@ -5,7 +5,6 @@ Enterprise Edition (look for the [`CE Upstream` merge requests]). This merge is done automatically in a [scheduled pipeline](https://gitlab.com/gitlab-org/release-tools/-/jobs/43201679). - If a merge is already in progress, the job [doesn't create a new one](https://gitlab.com/gitlab-org/release-tools/-/jobs/43157687). **If you are pinged in a `CE Upstream` merge request to resolve a conflict, @@ -16,10 +15,12 @@ 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 request before their CE counterpart +[`CE Upstream` merge requests]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?label_name%5B%5D=CE+upstream + +### 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 (if present).** +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: @@ -30,26 +31,27 @@ hours, it can happen that: merged yet 1. 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** -1. That's a waste of time, and that's why you should merge EE merge request - before their CE counterpart + +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 feature](ee_features.md). +[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 `rake ee_compat_check` CI job tries to +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? +#### How the job works 1. Generates the diff between your branch and current CE `master` 1. Tries to apply it to current EE `master` @@ -69,9 +71,9 @@ Notes: - This task is not a silver-bullet, its current goal is to bring awareness to developers that their work needs to be ported to EE. -- Community contributors shouldn't submit merge requests against EE, but - reviewers should take actions by either creating such EE merge request or - asking a GitLab developer to do it **before the merge request is merged**. +- Community contributors shouldn't be required to submit merge requests against + EE, but reviewers should take actions by either creating such EE merge request + or asking a GitLab developer to do it **before the merge request is merged**. - If you branch is too far behind `master`, the job will fail. In that case you should rebase your branch upon latest `master`. - Code reviews for merge requests often consist of multiple iterations of @@ -82,7 +84,7 @@ Notes: This helps to identify significant conflicts sooner, but also reduces the number of times you have to resolve conflicts. - Please remember to - [always have you EE merge request merged before the CE one](#always-merge-ee-merge-request-before-their-ce-counterpart). + [always have your EE merge request merged before the CE version](#always-merge-ee-merge-requests-before-their-ce-counterparts). - You can use [`git rerere`](https://git-scm.com/blog/2010/03/08/rerere.html) to avoid resolving the same conflicts multiple times. diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index eb33d17443a533bb9ea3c4c2c7c8079a8e7301e0..1af839a27e133a3762b443bdabf5a626d4c46160 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -1,4 +1,4 @@ -# Guidelines for implementing Enterprise Edition feature +# Guidelines for implementing Enterprise Edition features - **Write the code and the tests.**: As with any code, EE features should have good test coverage to prevent regressions. diff --git a/doc/development/writing_documentation.md b/doc/development/writing_documentation.md index b6def7ef5416ef6b3197854a5be107ea1ddbf2de..48e04a40050242151d6e0e19e4d76af0f9238fc2 100644 --- a/doc/development/writing_documentation.md +++ b/doc/development/writing_documentation.md @@ -142,7 +142,7 @@ tests. If it doesn't, the whole test suite will run (including docs). --- When you submit a merge request to GitLab Community Edition (CE), there is an -additional job called `rake ee_compat_check` that runs against Enterprise +additional job called `ee_compat_check` that runs against Enterprise Edition (EE) and checks if your changes can apply cleanly to the EE codebase. If that job fails, read the instructions in the job log for what to do next. Contributors do not need to submit their changes to EE, GitLab Inc. employees