- Act as SaaS
- Act as CE when unlicensed
- CI pipelines in a FOSS context
- Separation of EE code
- JavaScript code in
assets/javascripts/
-
Vue code in
assets/javascript
-
SCSS code in
assets/stylesheets
- GitLab-svgs
Guidelines for implementing Enterprise Edition features
- Write the code and the tests.: As with any code, EE features should have good test coverage to prevent regressions.
-
Write documentation.: Add documentation to the
doc/
directory. Describe the feature and include screenshots, if applicable. Indicate what editions the feature applies to. -
Submit a MR to the
www-gitlab-com
project.: Add the new feature to the EE features list.
Act as SaaS
When developing locally, there are times when you need your instance to act like the SaaS version of the product. In those instances, you can simulate SaaS by exporting an environment variable as seen below:
export GITLAB_SIMULATE_SAAS=1
There are many ways to pass an environment variable to your local GitLab instance.
For example, you can create a env.runit
file in the root of your GDK with the above snippet.
Act as CE when unlicensed
Since the implementation of
GitLab CE features to work with unlicensed EE instance
GitLab Enterprise Edition should work like GitLab Community Edition
when no license is active. So EE features always should be guarded by
project.feature_available?
or group.licensed_feature_available?
(or
License.feature_available?
if it is a system-wide feature).
Frontend features should be guarded by pushing a flag from the backend by using push_licensed_feature
, and checked using this.glFeatures.someFeature
in the frontend. For example:
<script>
import glFeatureFlagMixin from '~/vue_shared/mixins/gl_feature_flags_mixin';
export default {
mixins: [glFeatureFlagMixin()],
components: {
EEComponent: () => import('ee_component/components/test.vue'),
},
computed: {
shouldRenderComponent() {
return this.glFeatures.myEEFeature;
}
},
};
</script>
<template>
<div>
<ee-component v-if="shouldRenderComponent"/>
</div>
</template>
Look in ee/app/models/license.rb
for the names of the licensed features.
CE specs should remain untouched as much as possible and extra specs
should be added for EE. Licensed features can be stubbed using the
spec helper stub_licensed_features
in EE::LicenseHelpers
.
You can force GitLab to act as CE by either deleting the ee/
directory or by
setting the FOSS_ONLY
environment variable
to something that evaluates as true
. The same works for running tests
(for example FOSS_ONLY=1 yarn jest
).
Running feature specs as CE
When running feature specs as CE, you should ensure that the edition of backend and frontend match. To do so:
-
Set the
FOSS_ONLY=1
environment variable:export FOSS_ONLY=1
-
Start GDK:
gdk start
-
Run feature specs:
bin/rspec spec/features/<path_to_your_spec>
CI pipelines in a FOSS context
By default, merge request pipelines for development run in an EE-context only. If you are developing features that differ between FOSS and EE, you may wish to run pipelines in a FOSS context as well.
To run pipelines in both contexts, add the ~"pipeline:run-as-if-foss"
label to the merge request.
See the As-if-FOSS jobs pipelines documentation for more information.
Separation of EE code
All EE code should be put inside the ee/
top-level directory. The
rest of the code should be as close to the CE files as possible.
EE-only features
If the feature being developed is not present in any form in CE, we don’t
need to put the code under the EE
namespace. For example, an EE model could
go into: ee/app/models/awesome.rb
using Awesome
as the class name. This
is applied not only to models. Here’s a list of other examples:
ee/app/controllers/foos_controller.rb
ee/app/finders/foos_finder.rb
ee/app/helpers/foos_helper.rb
ee/app/mailers/foos_mailer.rb
ee/app/models/foo.rb
ee/app/policies/foo_policy.rb
ee/app/serializers/foo_entity.rb
ee/app/serializers/foo_serializer.rb
ee/app/services/foo/create_service.rb
ee/app/validators/foo_attr_validator.rb
ee/app/workers/foo_worker.rb
ee/app/views/foo.html.haml
ee/app/views/foo/_bar.html.haml
This works because for every path that is present in CE’s eager-load/auto-load
paths, we add the same ee/
-prepended path in config/application.rb
.
This also applies to views.
Testing EE-only features
To test an EE class that doesn’t exist in CE, create the spec file as you normally
would in the ee/spec
directory, but without the second ee/
subdirectory.
For example, a class ee/app/models/vulnerability.rb
would have its tests in ee/spec/models/vulnerability_spec.rb
.
EE features based on CE features
For features that build on existing CE features, write a module in the EE
namespace and inject it in the CE class, on the last line of the file that the
class resides in. This makes conflicts less likely to happen during CE to EE
merges because only one line is added to the CE class - the line that injects
the module. For example, to prepend a module into the User
class you would use
the following approach:
class User < ActiveRecord::Base
# ... lots of code here ...
end
User.prepend_mod
Do not use methods such as prepend
, extend
, and include
. Instead, use
prepend_mod
, extend_mod
, or include_mod
. These methods will try to
find the relevant EE module by the name of the receiver module, for example;
module Vulnerabilities
class Finding
#...
end
end
Vulnerabilities::Finding.prepend_mod
will prepend the module named ::EE::Vulnerabilities::Finding
.
If the extending module does not follow this naming convention, you can also provide the module name
by using prepend_mod_with
, extend_mod_with
, or include_mod_with
. These methods take a
String containing the full module name as the argument, not the module itself, like so;
class User
#...
end
User.prepend_mod_with('UserExtension')
Since the module would require an EE
namespace, the file should also be
put in an ee/
sub-directory. For example, we want to extend the user model
in EE, so we have a module called ::EE::User
put inside
ee/app/models/ee/user.rb
.
This is also not just applied to models. Here’s a list of other examples:
ee/app/controllers/ee/foos_controller.rb
ee/app/finders/ee/foos_finder.rb
ee/app/helpers/ee/foos_helper.rb
ee/app/mailers/ee/foos_mailer.rb
ee/app/models/ee/foo.rb
ee/app/policies/ee/foo_policy.rb
ee/app/serializers/ee/foo_entity.rb
ee/app/serializers/ee/foo_serializer.rb
ee/app/services/ee/foo/create_service.rb
ee/app/validators/ee/foo_attr_validator.rb
ee/app/workers/ee/foo_worker.rb
Testing EE features based on CE features
To test an EE
namespaced module that extends a CE class with EE features,
create the spec file as you normally would in the ee/spec
directory, including the second ee/
subdirectory.
For example, an extension ee/app/models/ee/user.rb
would have its tests in ee/spec/models/ee/user_spec.rb
.
In the RSpec.describe
call, use the CE class name where the EE module would be used.
For example, in ee/spec/models/ee/user_spec.rb
, the test would start with:
RSpec.describe User do
describe 'ee feature added through extension'
end
Overriding CE methods
To override a method present in the CE codebase, use prepend
. It
lets you override a method in a class with a method from a module, while
still having access the class’s implementation with super
.
There are a few gotchas with it:
- you should always
extend ::Gitlab::Utils::Override
and useoverride
to guard theoverrider
method to ensure that if the method gets renamed in CE, the EE override isn’t silently forgotten. - when the
overrider
would add a line in the middle of the CE implementation, you should refactor the CE method and split it in smaller methods. Or create a “hook” method that is empty in CE, and with the EE-specific implementation in EE. -
when the original implementation contains a guard clause (for example,
return unless condition
), we cannot easily extend the behavior by overriding the method, because we can’t know when the overridden method (that is, callingsuper
in the overriding method) would want to stop early. In this case, we shouldn’t just override it, but update the original method to make it call the other method we want to extend, like a template method pattern. For example, given this base:class Base def execute return unless enabled? # ... # ... end end
Instead of just overriding
Base#execute
, we should update it and extract the behavior into another method:class Base def execute return unless enabled? do_something end private def do_something # ... # ... end end
Then we’re free to override that
do_something
without worrying about the guards:module EE::Base extend ::Gitlab::Utils::Override override :do_something def do_something # Follow the above pattern to call super and extend it end end
When prepending, place them in the ee/
specific sub-directory, and
wrap class or module in module EE
to avoid naming conflicts.
For example to override the CE implementation of
ApplicationController#after_sign_out_path_for
:
def after_sign_out_path_for(resource)
current_application_settings.a