JiHu Support

How the GitLab Inc team provides support to JiHu


As announced in the blog post GitLab licensed its technology to new independent Chinese company, GitLab Inc. has licensed its technology to JiHu. This page is outlines how the GitLab Inc. team provides support to JiHu.


Please refer to our guidelines


Please refer to our guidelines. Invitations sent to GitLab Team members to join the gitlab-jh.slack.com Slack server are legitimate. This server is used for communications between GitLab Inc. and JiHu.


Please refer to our guidelines.

Professional Services

Please refer to our guidelines (link to be added).

Customer Support

Process to be added below.


R&D Roles

DRI Role
Mek Stittri Engineering DRI
Kevin Chu Product DRI
Lin Jen-Shin Engineering Facilitator


JiHu team projects are located at https://jihulab.com/gitlab-cn/. Mirrored projects for gitlab-org tooling and compliance checks are available at https://gitlab.com/gitlab-org/gitlab-jh-mirrors/.

Even though most of the JiHu projects are moved to JiHuLab.com, some projects are still under the gitlab-jh group. To request access please reach out to Kevin or Mek to provision.

GitLab Inc Project JiHu Project
https://gitlab.com/gitlab-org/gitlab https://jihulab.com/gitlab-cn/gitlab
https://gitlab.com/gitlab-org/license-gitlab-com https://gitlab.com/gitlab-jh/license-gitlab-cn (private)
https://gitlab.com/gitlab-org/customers-gitlab-com https://jihulab.com/jihulab/engineering/customers-jihulab-com (private)
https://gitlab.com/gitlab-services/version-gitlab-com https://gitlab.com/gitlab-jh/version-gitlab-cn
https://gitlab.com/gitlab-org/omnibus-gitlab https://jihulab.com/gitlab-cn/omnibus-gitlab
https://gitlab.com/gitlab-org/gitaly https://jihulab.com/gitlab-cn/gitaly
https://gitlab.com/gitlab-org/gitlab-environment-toolkit https://gitlab.com/gitlab-jh/gitlab-environment-toolkit
https://gitlab.com/gitlab-org/build/CNG https://jihulab.com/gitlab-cn/build/cng-images
https://gitlab.com/gitlab-org/charts/gitlab https://jihulab.com/gitlab-cn/charts/gitlab
https://gitlab.com/gitlab-org/gitlab-docs https://jihulab.com/gitlab-cn/gitlab-docs-cn
https://gitlab.com/gitlab-org/gitlab-runner https://jihulab.com/gitlab-cn/gitlab-runner
https://gitlab.com/gitlab-org/gitlab-svgs https://jihulab.com/gitlab-cn/gitlab-svgs
https://gitlab.com/gitlab-org/gitlab-qa https://jihulab.com/gitlab-cn/gitlab-qa

JiHu contribution process

Please refer to JiHu contribution process for details.

Broken JiHu main branch resolution process

There are times where main-jh branch is broken and requires upstream merge requests to resolve. When this happens the following process will be enacted for a timely resolution within 2 business days of JiHu upstream MR creation.

  1. JiHu team will open an upstream MR with the resolution
  2. JiHu Engineering DRI will notify GitLab Inc with a message in #main-jh-broken to identify that the MR is escalated to the GitLab maintainers
  3. GitLab Facilitator will apply ~"JiHu Broken Pipeline" label to the merge request and solicit a review from the appropriate domain (backend, frontend).
  4. GitLab Facilitator will notify GitLab Inc team members in the #jihu-engineering channel.
  5. JiHu will add the MR and root cause of the failure to https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/215

Merge requests with broken JiHu validation pipeline

Check What to do when the validation pipeline failed for more details.

Security Release Process

JiHu is responsible for building and releasing the JiHu Edition each month including all patch and security releases. For security releases, GitLab Inc will continue to follow our existing security release process to publish our security releases. To enable JiHu to build their security releases in a timely manner, GitLab Inc will notify JiHu when a security release is in progress along so that their teams can be on stand by. GitLab Inc will not notify JiHu of the contents of the security release or of the vulnerability.

To notify JiHu of an upcoming security release, please simply post a comment in: https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/112

Vulnerability Disclosure Process

GitLab Inc will follow the documented vulnerability disclosure process and will not provide detailed information about vulnerabilities directly to JiHu. No information will be shared prior to or during an in-progress security release.

Only after a GitLab security release, GitLab Inc may provide JiHu with:

  • A link to the public security release blog post
  • A link to the GitLab issue describing the vulnerability, which will remain confidential until 30 days after the release in which the vulnerability was patched

This information will be communicated via Slack and the weekly engineering sync with JiHu.

For security vulnerabilities introduced by JiHu contributions, the GitLab Application Security team will share mitigation steps as long as they do not disclose vulnerability details or information that could result in the discovery of vulnerability details.

  • If such mitigation steps exist, the GitLab Application Security team will notify JiHu by creating a confidential issue in the JiHu enablement project with the mitigation steps.
  • If no mitigation steps exist, the vulnerability will be disclosed as per GitLab’s regular security vulnerability disclosure process.

Security Best Practices

GitLab can share security best practices with JiHu. This may include defense in depth measures, hardening techniques, and other information in the interest of keeping GitLab, JiHu, and their customers secure. This can not include vulnerability details or specific remediations that could expose information about an unpatched vulnerability or ongoing incident.

Consulting Process

JiHu benefits from GitLab expertise, particularly around operating GitLab as a SaaS product. GitLab may charge JiHu for consulting on items that require engagement beyond a quick response on Slack. This way, GitLab can safeguard against unplanned work while JiHu builds its domain expertise. This is also agreed upon in GitLab’s Technical Services Agreement with JiHu - Internal.

Topics not in scope for consulting

  • Reviewing MRs
  • Roadmap alignment
  • Management collaboration


Role of the Product DRI

The Product DRI has the following responsibilities:

  • Provide product management practice guidance to the JiHu CTO and product counterparts
  • Enable alignment between GitLab Product and JiHu Product
    • Provide regular updates and raise awareness of GitLab investment themes and roadmap
    • Disseminate JiHu plans and roadmap with the appropriate party
  • Liaise with JiHu CTO on product data
  • Work with stage groups to implement solutions that pertains to JiHu or China related requirements
  • Partner with Engineering DRI and Engineering Facilitators to define and maintain processes that ensures the smooth functioning between GitLab and JiHu

Product Manager responsibilities

JiHu contributions are similar to community contributions. The difference is they are higher in volume and frequency. As JiHu ramps up in the GitLab codebase, they are also eager to build understanding and learn where and how they might contribute to GitLab. Product Managers can share their public directions and work with the JiHu team to help JiHu become self-sufficient and efficient.

At times, product managers are asked to provide feedback or directly respond to specific proposals from JiHu. GitLab PMs should help facilitate collaboration between GitLab engineers and the JiHu team. This means if there’s misalignment on product direction, call that out early so JiHu doesn’t spend time working on things GitLab doesn’t intend to merge.

If product managers need help connecting with JiHu counterparts, ping the Product DRI in #jihu-product.

Product Designer responsibilities

GitLab Product Designers are responsible for reviews and guidance and should not take over the complete design work for issues that JiHu wants to contribute, as JiHu has their own Product Design team that will help get these issues ready for implementation.


Once a Product Designer gets pinged on an issue that JiHu intends to contribute upstream, the Product Designer reviews whether that issue already has a clear proposal that does not conflict with our Pajamas guidelines, the Product principles or planned work of their team.

If there is no clear design proposal yet, or there are conflicts with Pajamas or the Product principles, the designer leaves a comment about what is required before the issue should go into implementation.

Milestone Product Planning Process with JiHu

To facilitate collaboration and feedback, JiHu plans ahead of GitLab’s milestone planning process to give GitLab product groups time to provide feedback ahead of implementation. The following will happen every milestone:

  1. JiHu will create a milestone planning issue in the gitlab-jh-enablement project, such as this example. JiHu typically provides the plan 2 weeks before the 18th of the month.
  2. For any items which do not already have an issue in the Gitlab.org project, the JiHu team creates an issue. If there is an existing issue, it is linked to from the milestone planning issue. This helps the GitLab product group track JiHu contributions in the same place where other day to day work is tracked.
  3. The Product DRI will facilitate awareness and encourage collaboration via the JiHu Milestone Review Template
  4. Individual product manager and their engineering counterparts will provide feedback to JiHu as needed
Large Product Iniative Planning

In the interest of creating IP, JiHu will take on larger product initiatives that spans multiple milestones. This type of product initiatives take more coordination. JiHu and GitLab representatives regularly stay in sync regarding these product plans. The goal is to identify large initiatives early so that the appropriate DRIs can be looped in. One example of this type of product initiative is the Visual Builder for the pipeline editor.

What product managers are not responsible for

GitLab Product Managers are not responsible for JiHu product decisions, but collaboration and feedback with JiHu Product Managers is encouraged and appreciated.

  • Just like PMs aren’t the arbiters of community contribution, product managers are not the arbiter of what the JiHu team works on
  • Product managers are not responsible for JiHu product decisions, such as tiering, pricing
  • When reviewing JiHu milestone planning:
    1. Be aware of JiHu’s plans in your product area.
    2. Provide guidance in accordance with GitLab’s product direction.
    3. Help avoid surprises and help JiHu be successful. If feedback will take some time, please provide a heads-up.
    4. It is not necessary to provide feedback if there’s no feedback to give. JiHu contribution can be the same as other community contributions

Differentiating Proprietary JiHu Features

We differentiate proprietary features for JiHu distributions by including them in the /jh directory. However, the majority of contributions from JiHu team members should be outside of the /jh directory signaling the expectation that most contributions are to GitLab Core and only certain specific features are exclusive to the /jh offering.

JiHu contribution process
Contributions from the JiHu team will follow two methods depending on whether they have JiHu proprietary changes or not. Upstream method - start with a merge request in the GitLab Inc. repository. Proprietary and upstream method - start with a merge request with all changes against the GitLab JiHu project and a merge request with all non-proprietary changes against the upstream project. To identify contributions from JiHu, the ~"JiHu contribution" label is automatically applied to all upstream contributions coming from the JiHu team.
JiHu guidelines for database changes
JiHu guidelines for database changes For JiHu contributions that contain database migrations (for PostgreSQL), there are two routes to consider: Upstream fully: Contribute the code change including database migrations upstream into GitLab Upstream migrations only: Only upstream database migrations without the code change (e.g. for a JiHu proprietary feature) The following details guidelines and background for (2): Upstream database migrations only, without the relevant code change. For changes that are going to be fully upstreamed including code changes, we follow the regular GitLab contribution workflow and the following does not apply.
JiHu Security Review Process
Security review process for JiHu contributions In order to make sure that a release with JiHu contributions can be certified, members of the AppSec team need to perform a security review of any JiHu contribution and explicitly approve them. The JiHu team will be contributing code to a number of repositories. These contributions will be auto labeled with the JiHu contribution label. graph TD A[JiHu Contribution Opened] -->|First merge request review approval| B(AppSec approval requested) B --> C["AppSec approves with MR approval and ~sec-planning::complete"] C --> D[Automated commit AppSec approval comment] D ---> E{Merge requests is updated} E -->|Yes| B E -->|No| F[Merge request can be merged] Who can perform a security review of a JiHu contribution Any member of the AppSec or Federal AppSec team is eligible to perform a security review of a JiHu contribution.
JiHu validation pipelines
JiHu validation pipelines In order to make sure our regular development does not break JiHu’s pipelines, we run JiHu validation pipelines in merge requests which we consider it’s more likely to break JiHu’s pipelines. Those pipelines are currently allowed to fail, and they should not block any merge requests from being merged. To revisit this policy, checkout: Disallow as-if-jh pipeline to fail When and where we run it We run the validation pipelines when we detected that the changes is more likely to break JiHu’s pipeline.
Release Certification
Process for Release Certification Every release with JiHu contributions needs to be certified by a member of the Federal Application Security team. This is required to satisfy PubSec/FedRamp requirements and to handle JiHu’s merge request contributions to GitLab Inc repositories. This process involves ensuring that each JiHu contribution included in the release has been reviewed and approved by an Application Security team member and posting a comment on the relevant release task issue that no new vulnerabilities have been identified in the code being released.
Last modified August 18, 2023: Big Broken Link Fix (f73576b8)