关于极狐（JH）版相关合并请求的审查指南

与 JH 相关的变更有两种：

• 在 jh/ 目录内
  • 这部分内容超出 EE 仓库范围，不在本文档的讨论范围内。
• 在 jh/ 目录外
  • 这些代码必须放在 EE 仓库中，因此 EE 仓库的审查者和维护者需要负责审查和维护。这包括类似 Gitlab.jh? 的代码，以及它如何尝试加载 jh/ 目录下的代码，就像我们有加载 ee/ 目录下代码的机制一样。
  • 本文档旨在指导这些代码应该如何编写，以便我们更好地理解查找 jh/ 目录下代码所需的变更。
  • 我们将对进行通用化处理，使 EE 和 JH 可以共享相同的机制，这样我们就不必区别对待它们。
  • 支持运行 JH 版本所需的数据库迁移和数据库架构变更。详情请参见 极狐数据库变更指南。

如有需要，请审查位于 JH 仓库 中的相应 JH 合并请求。

何时将文件合并到 GitLab Inc. 仓库

添加到 GitLab JH 仓库中 jh/ 目录之外的文件，必须在 GitLab Inc. 仓库中进行镜像。

如果添加到 GitLab Inc. 仓库的代码引用了（例如 render_if_exists）GitLab JH 中存在但 GitLab Inc. 代码库中不存在的任何文件，请添加注释并附上指向极狐合并请求或文件的链接。这是为了防止该引用被错误地识别为缺失的局部模板，并在 gitlab 代码库中被删除。

流程概览

请阅读以下流程指南：

• 贡献审查流程
• 数据库变更流程
• 安全审查流程
• 合并请求流程

当 jh/ 不存在或 EE_ONLY=1 时以 EE 模式运行

• 在 EE 仓库中，jh/ 目录不存在，因此它应该直接以 EE 模式运行（或者在许可证不存在时以 CE 模式运行）
• 在 JH 仓库中，jh/ 目录确实存在，但可以设置 EE_ONLY 环境变量来强制其以 EE 模式运行。

当 FOSS_ONLY=1 时以 FOSS 模式运行

• 在 JH 仓库中，jh/ 目录确实存在，但可以设置 FOSS_ONLY 环境变量来强制其以 FOSS（CE）模式运行。

JH 环境中的 CI 流水线

EE 仓库没有 jh/ 目录，因此无法在 EE 仓库中运行 JH 流水线。所有 JH 测试都应该提交到 JH 仓库。

顶层的 JH CI 配置位于 jh/.gitlab-ci.yml（EE 仓库中不存在），它会相应地包含 EE CI 配置。有时需要更新 EE CI 配置以便 JH 可以更轻松地进行定制。

基于 CE 或 EE 功能的 JH 功能

对于基于现有 CE/EE 功能构建的功能，需要在 CE/EE 类/模块中注入一个 JH 命名空间下的模块。这与我们对 EE 功能的做法一致。

更多详情请参见 使用 EE 后端代码扩展 CE 功能。

例如，要在 User 类中前置一个模块，可以使用以下方法：

class User < ActiveRecord::Base
  # ... lots of code here ...
end

User.prepend_mod

在 EE 中，User.prepend_mod 会尝试：

• 加载 EE 模块

在 JH 中，User.prepend_mod 会尝试：

• 加载 EE 模块，并且：
• 加载 JH 模块

不要使用 prepend、extend 和 include 等方法。相反，请使用 prepend_mod、extend_mod 或 include_mod。这些方法会尝试根据接收器模块的名称查找相关的 EE 和 JH 模块。

如果需要审查相应的 JH 文件，它应该在 JH 仓库 中找到。

# Added for JiHu
# Used in https://jihulab.com/gitlab-cn/gitlab/-/blob/main-jh/jh/lib/jh/api/integrations.rb
API::Integrations.prepend_mod

编写 JH 扩展的一般指导

一般性指导请参见 企业版功能实现指南。