JH only gems
Background
In gitlab-jh/gitlab!67 (closed) we need to install gems which only needed by JH edition, and how should we proceed with it?
For EE only gems, we generally just add it to Gemfile
and FOSS will have to install those gems anyway.
But can we do the same for JH?
Selected solution:
Introduce jh/Gemfile
:
- !69361 (merged)
- !69389 (merged)
- !69461 (merged)
- gitlab-jh/gitlab!76 (merged)
- gitlab-development-kit!2147 (merged)
- omnibus-gitlab!5570 (merged)
Potential solutions
- Put JH only gems inside
Gemfile
andGemfile.lock
, just like what we did for EE, and potentially under:jh
group.- Do we update all the building scripts so bundler will ignore
:jh
group for EE and FOSS? - Or do we just install those JH gems anyway?
- Pros:
- No conflicts
- Easy to manage
- Cons:
- Install extra gems when not needed for EE, or we need to update a lot of build scripts to explicitly ignore
:jh
group - Changes will always need to be ported to EE rather than self-contained in JH
- Install extra gems when not needed for EE, or we need to update a lot of build scripts to explicitly ignore
- Do we update all the building scripts so bundler will ignore
- Put JH only gems inside
Gemfile
but withinGitlab.jh
block, so it'll only be installed when it's running under JH mode- Pros:
- No need to install extra gems in EE, nor do we need to update build scripts
- Cons:
- This will cause JH
Gemfile.lock
conflicting with EE, leaving divergence, and extra manual work to resolve the conflicts when it happenes - Changes will always need to be ported to EE rather than self-contained in JH
- This will cause JH
- Pros:
- Do not put changes inside EE, just add them to JH
- Pros:
- No extra work for EE
- Changes will be self-contained in JH
- Cons:
- This will cause JH
Gemfile
andGemfile.lock
conflicting with EE, leaving divergence, and extra manual work to resolve the conflicts when it happens
- This will cause JH
- Pros:
- Put JH only gems inside
jh/Gemfile
andjh/Gemfile.lock
, and setenv BUNDLE_GEMFILE=jh/Gemfile
when we're running under JH mode- Pros:
- No extra work for EE
- Changes will be self-contained in JH
- Cons:
- Setting
BUNDLE_GEMFILE=jh/Gemfile
can be tricky and break a lot of build scripts. A lot of build scripts might need to be updated in order to properly reflect that
- Setting
- Pros:
- Some magic bundler feature?
- Some GitLab brewed bundler feature?
Edited by Lin Jen-Shin