Guidelines for reviewing JiHu (JH) Edition related merge requests
We have two kinds of changes related to JH:
- Inside
jh/
- This is beyond EE repository and not the intention for this documentation.
- Outside
jh/
- These will have to sit in EE repository, so reviewers and maintainers for
EE repository will have to review and maintain. This includes codes like
Gitlab.jh?
, and how it attempts to load codes underjh/
just like we have codes which will load codes underee/
. - This documentation intended to guide how those codes should look like, so
we’ll have better understanding what are the changes needed for looking up
codes under
jh/
. - We will generalize this so both EE and JH can share the same mechanism, then we wouldn’t have to treat them differently.
- Database migrations and database schema changes which are required to support running JH edition. See JiHu guidelines for database changes for details.
- These will have to sit in EE repository, so reviewers and maintainers for
EE repository will have to review and maintain. This includes codes like
If needed, review the corresponding JH merge request located at JH repository.
When to merge files to the GitLab Inc. repository
Files that are added to the GitLab JH repository outside of jh/
must be mirrored in the GitLab Inc. repository.
If code that is added to the GitLab Inc. repository references (for example, render_if_exists
) any GitLab JH file that does not
exist in the GitLab Inc. codebase, add a comment with a link to the JiHu merge request or file. This is to prevent
the reference from being misidentified as a missing partial and subsequently deleted in the gitlab
codebase.
Process overview
Read the following process guides:
Act as EE when jh/
does not exist or when EE_ONLY=1
- In the case of EE repository,
jh/
does not exist so it should just act like EE (or CE when the license is absent) - In the case of JH repository,
jh/
does exist butEE_ONLY
environment variable can be set to force it run under EE mode.
Act as FOSS when FOSS_ONLY=1
- In the case of JH repository,
jh/
does exist butFOSS_ONLY
environment variable can be set to force it run under FOSS (CE) mode.
CI pipelines in a JH context
EE repository does not have jh/
directory therefore there is no way to run
JH pipelines in the EE repository. All JH tests should go to JH repository.
The top-level JH CI configuration is located at jh/.gitlab-ci.yml
(which
does not exist in EE repository) and it’ll include EE CI configurations
accordingly. Sometimes it’s needed to update the EE CI configurations for JH
to customize more easily.
JH features based on CE or EE features
For features that build on existing CE/EE features, a module in the JH
namespace injected in the CE/EE class/module is needed. This aligns with
what we’re doing with EE features.
See Extend CE features with EE backend code for more details.
For example, to prepend a module into the User
class you would use
the following approach:
class User < ActiveRecord::Base
# ... lots of code here ...
end
User.prepend_mod
Under EE, User.prepend_mod
will attempt to:
- Load EE module
Under JH, User.prepend_mod
will attempt to:
- Load EE module, and:
- Load JH module
Do not use methods such as prepend
, extend
, and include
. Instead, use
prepend_mod
, extend_mod
, or include_mod
. These methods will try to find
the relevant EE and JH modules by the name of the receiver module.
If reviewing the corresponding JH file is needed, it should be found at JH repository.
prepend_mod
for the modules. When we do this,
also add a comment mentioning it, and a link to the JH module using it.
This way we know where it’s used and when we might not need it anymore,
and we do not remove them only because we’re not using it, accidentally
breaking JH. An example of this:# Added for JiHu
# Used in https://jihulab.com/gitlab-cn/gitlab/-/blob/main-jh/jh/lib/jh/api/integrations.rb
API::Integrations.prepend_mod
General guidance for writing JH extensions
See Guidelines for implementing Enterprise Edition features for general guidance.