Skip to content

JH edition code structure

Background

We have EE as an extension to CE (FOSS), and now we're going to have JH (JiHu) as an extension to EE. The information about how we structure our codes and licenses can be found at https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/tree/master/handbook/engineering

One thing which is notably different is that EE and CE are using the same repository, while JH contents will sit in their own repository. This illustrates the mirroring flow:

(add `jh/`) JH <- EE -> FOSS (remove `ee/`)

There are a few areas we need to figure out for the best approach.

CI configurations

Since JH codes will sit in their own repository, it'll work better if JH CI configurations also sit in their own repository. In order to do this, we're likely to change the default CI configuration path to point it to jh/.gitlab-ci.yml instead. From there, we can include other files we originally used.

This is described in gitlab-jh/gitlab#7 (closed)

At the very first CI was implemented in gitlab-jh/gitlab!3 (merged) and we'll need to follow up from there. It's likely that we'll need to make a lot of updates to our CI configurations so it's easier to customize and extend CI configurations needed for JH.

Additionally, JH CI should be configured to run only under JH mode, because EE/FOSS testes should be taken care in the original repository already.

Given this, if jh/ directory is presented, it'll default to run under JH mode. Therefore EE_ONLY environment variable is introduced. This leads to the next topic.

EE_ONLY

EE_ONLY was introduced in gitlab-jh/gitlab!6 (merged)

Generally unless someone is working on both JH and EE at the same time, it's unlikely they'll need to use this to enable EE mode.

However it's likely that JH team will need to use EE_ONLY to debug failures in EE while they're contributing back upstream for the codes outside of jh/.

Is there a better approach than this?

What about tests which can never pass in JH?

There are tests which are verifying if it's pointing to the right URLs. Essentially now those should be configurable, because JH will need to change those URLs.

We can see that it's impossible to pass those tests in JH, and this can be found in both:

For now we added conditions to skip those tests, but this is ugly and it's not scalable. What should we do here?

  • Just remove those tests. They're just checking if some static values are matching some static values. Essentially configuration tests which might not be too valuable.
  • It's fine to skip them like this
  • Is there a way that we can have tests which run and only run under EE or CE? It's the same as skipping those tests, but with a more elegant way to specify that? We have ee/spec/ which only runs under EE mode, but JH is also a kind of EE because it's an extension to EE and we can't skip codes under Gitlab.ee? otherwise they won't be available in JH.

What is the best approach here?

Gitlab.com? and Gitlab.sass? and Gitlab.jh? and Gitlab.ee?

We're also discussing about dropping Gitlab.com? in #225101 (closed)

We once introduced com/ to include codes only needed for GitLab.com, which is actually pretty similar to what we do for JH today. But it was reverted: !18212 (merged)

The context can be found at: &1969 (closed)

I imagine we might or might not want to have codes under Gitlab.com? to run for JH as well. For example, we want to have the followings for JH:

  • It's a SaaS, we need to keep the codes around plans and subscriptions. Those may be changed to be using Gitlab.saas? instead of Gitlab.com?

However we won't want to have everything under GitLab.com for JH:

  • We're going to have some GitLab.com specific things, like URLs, trademarks, and logos are obvious. There can be more. Do they keep under Gitlab.com?? Or should we introduce com/ back, and JH should just remove the com/ directory? If we have com/, then we can put the tests which will never pass in JH mentioned above under com/spec/ then we'll solve these problems as well.

And now EE can be ambiguous and confusing:

  • Gitlab.ee? will need to return true under JH for now. Can this be confusing? How can we improve this? Will we need Gitlab.only_ee_not_jh?? If so, can it be covered with Gitlab.com? Or maybe it's still different?

To be added

I believe there are more topics I haven't covered yet. I'll add them to this issue as we go and explore.

/cc @kwiebers @jeromezng

Edited by Lin Jen-Shin