How to enable a feature flag in gitlab-ce? - gitlab

Question

We upgraded our self-hosted gitlab-ce to the latest 11.11 which brings in multiple reviewer merge request approval feature. Although this needs to be explicitly enabled via gitlab-rails console.
On the machine running our gitlab instance, I ran gitlab-rails console and got to a ruby console where I put in Feature.enable(:approval_rules) and hit Enter but I get:
>> Feature.enable(:approval_rules)
Nothing known about Feature.enable(
I do not have much experience with ruby so am not sure what am doing wrong. I searched on the web but I found documentation on how to develop with Ruby's "feature flags" but not how to enable them as a end user of the application.

Answer 1

You can do it via the GitLab api.
POST to https://gitlab.myhost.com/api/v4/features/approval_rules with the payload
{
"value": true
}
https://docs.gitlab.com/ee/api/features.html
Additionally, I found that the new approval rules workflow was automatically enabled upon upgrading from 11.9 to 11.10, though my experience may be different. If you perform a GET to that API endpoint, you will be able to see its current status.
If it is already enabled, perhaps you may be mistaking the new approval rules implementation with the EE feature Multiple Approval Rules. I only mention due to the -ce tag in your question.

Answer 2

With GitLab 13.5 (October 2020), actual feature flags are available for all:
Feature Flags made available in all tiers
In GitLab 11.4, we introduced Feature Flags.
In GitLab 12.2, we introduced percent rollout and user ID Feature Flag strategies.
In GitLab 13.1, we introduced Feature Flag user lists and support for multiple Feature Flag strategies per environment.
Earlier this year, we committed to moving 18 features to our open source Core product and took the first step in delivering on this promise by making Feature Flags available in Starter in the last release.
Now we’ve officially finished moving Feature Flags to our Core offering. We’re excited about making these features available to more of the GitLab community and seeing the positive impact it’ll have on your development workflow.
See Documentation and Issue.
That includes, still with GitLab 13.5 (October 2020):
Feature Flags flexible rollout strategy
When you use the percent rollout strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy.
We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.
See Documentation and Issue.
The feature flag API is more about creation/update/deletion.
You will have to use a feature flag strategy in order to enable/disable a feature flag.
Feature.disable(:feature_flags_new_version)
Feature.enable(:feature_flags_new_version)
See also GitLab 13.6 (November 2020)
Fire Webhook on Feature Flag change
As a developer, you can use GitLab’s webhook features for various events, such as MR events, pipeline events, job events, and deployment events. In this release, you can now use webhook events when a feature flag is toggled either on or off. This addition streamlines the process to update your CI/CD pipelines, receive Slack notifications for events, and more. A huge thanks to Sashi for a great community contribution!
See Documentation and Issue.