1--- 2stage: none 3group: unassigned 4info: https://gitlab.com/gitlab-jh/gitlab 5--- 6 7# Guidelines for reviewing JiHu (JH) Edition related merge requests 8 9We have two kinds of changes related to JH: 10 11- Inside `jh/` 12 - This is beyond EE repository and not the intention for this documentation. 13- Outside `jh/` 14 - These will have to sit in EE repository, so reviewers and maintainers for 15 EE repository will have to review and maintain. This includes codes like 16 `Gitlab.jh?`, and how it attempts to load codes under `jh/` just like we 17 have codes which will load codes under `ee/`. 18 - This documentation intended to guide how those codes should look like, so 19 we'll have better understanding what are the changes needed for looking up 20 codes under `jh/`. 21 - We will generalize this so both EE and JH can share the same mechanism, 22 then we wouldn't have to treat them differently. 23 24If needed, review the corresponding JH merge request located at [JH repository](https://gitlab.com/gitlab-jh/gitlab) 25 26## When to merge files to the GitLab Inc. repository 27 28Files that are added to the `gitlab-jh` repository outside of `jh/` must be mirrored in the GitLab Inc. repository. 29 30If code that is added to the GitLab Inc. repository references (for example, `render_if_exists`) any `gitlab-jh` file that does not 31exist in the GitLab Inc. codebase, add a comment with a link to the JiHu merge request or file. This is to prevent 32the reference from being misidentified as a missing partial and subsequently deleted in the `gitlab` codebase. 33 34## Process overview 35 36See the [merge request process](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/#merge-request-process) 37on the JiHu Support handbook. 38This page is the single source of truth for JiHu-related processes. 39 40## Act as EE when `jh/` does not exist or when `EE_ONLY=1` 41 42- In the case of EE repository, `jh/` does not exist so it should just act like EE (or CE when the license is absent) 43- In the case of JH repository, `jh/` does exist but `EE_ONLY` environment variable can be set to force it run under EE mode. 44 45## Act as FOSS when `FOSS_ONLY=1` 46 47- In the case of JH repository, `jh/` does exist but `FOSS_ONLY` environment variable can be set to force it run under FOSS (CE) mode. 48 49## CI pipelines in a JH context 50 51EE repository does not have `jh/` directory therefore there is no way to run 52JH pipelines in the EE repository. All JH tests should go to [JH repository](https://gitlab.com/gitlab-jh/gitlab). 53 54The top-level JH CI configuration is located at `jh/.gitlab-ci.yml` (which 55does not exist in EE repository) and it'll include EE CI configurations 56accordingly. Sometimes it's needed to update the EE CI configurations for JH 57to customize more easily. 58 59### JH features based on CE or EE features 60 61For features that build on existing CE/EE features, a module in the `JH` 62namespace injected in the CE/EE class/module is needed. This aligns with 63what we're doing with EE features. 64 65See [EE features based on CE features](ee_features.md#ee-features-based-on-ce-features) for more details. 66 67For example, to prepend a module into the `User` class you would use 68the following approach: 69 70```ruby 71class User < ActiveRecord::Base 72 # ... lots of code here ... 73end 74 75User.prepend_mod 76``` 77 78Under EE, `User.prepend_mod` will attempt to: 79 80- Load EE module 81 82Under JH, `User.prepend_mod` will attempt to: 83 84- Load EE module, and: 85- Load JH module 86 87Do not use methods such as `prepend`, `extend`, and `include`. Instead, use 88`prepend_mod`, `extend_mod`, or `include_mod`. These methods will try to find 89the relevant EE and JH modules by the name of the receiver module. 90 91If reviewing the corresponding JH file is needed, it should be found at 92[JH repository](https://gitlab.com/gitlab-jh/gitlab). 93 94### General guidance for writing JH extensions 95 96See [Guidelines for implementing Enterprise Edition features](ee_features.md) 97for general guidance. 98