Gitlab unleash client
What does this MR do?
Creates a gitlab unleash client to allow gitlab itself to use unleash for feature flag management of itself.
The following are concerns mentioned in #211687.
Instantiate the Unleash client and configure it to pull feature flags from our chosen GitLab instance.
To do this we need to have a URL and Instance ID for a gitlab feature flags instance. We could use a project on ops.gitlab.net to host our flags, for example. We'll need to capture these two values and set them in the gitlab settings configuration file.
Use our existing Flipper-based feature flags to control this so we can turn the Unleash client off and on for gitlab.com. Ideally, we would be able to turn it off completely with a feature flag so that it stops making HTTP requests.
The initializer will feed the
enabled setting through to the client's
disable_client parameter that will entirely turn off the client so that it makes no HTTP requests at all. We can also set this value via a Flipper feature flag.
When this Flipper feature flag is disabled, code that uses the new Unleash API should default to returning the supplied default-enabled values rather than trying to make a request to Unleash.
Make up a very simple feature that we would like to be able to toggle off and on for gitlab.com with no intention of shipping to self-managed instances. Maybe change the color of a button or something similarly trivial. Or perhaps we could find a simple change we would actually like to get feedback on. Use the configured Unleash client (perhaps wrapped in our own code) to turn it on or off based on user id with a userWithId strategy.
This commit shows example usage and adds a feature to make section titles in the CI/CD views consistently titlecase: !28980 (2f7deda2)
Logging is probably something we want to setup properly at this point, or at least it needs to be considered.
This MR adds a JSON logger for Unleash.
Hopefully we don't need more caching at this point than what the Unleash client already provides. This estimate assumes we don't, but we probably have to think about it at this point and decide if that holds up or not.
This MR does not address this topic. I just want to call that out for clarity. We may need more MRs to close out this issue.
The Unleash gem probably needs to be upgraded.
This MR upgrades it to the latest version: 3.2.0.
Collect Unleash Metrics (for logging purposes)
This MR does not address metrics. A subsequent MR will do so.
As part of this MR we added more Unleash client settings, there is a corresponding MR for omnibus related to this: omnibus-gitlab!4076
Does this MR meet the acceptance criteria?
- Changelog entry
- Documentation (if required)
- Code review guidelines
- Merge request performance guidelines
- Style guides
- [-] Database guides
- [-] Separation of EE specific content
Availability and Testing
- Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
- [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
Label as security and @ mention
- The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- Security reports checked/validated by a reviewer from the AppSec team