Make secrets check an ultimate feature
What does this MR do and why?
This merge request adds the following identifier in GitlabSubscriptions::Features::ULTIMATE_FEATURES as per the docs:
pre_receive_secret_detection
It also updates the secrets push check introduced in !135032 (merged) to mark it as an ultimate feature, according to the guidelines.
Resolves #427040 (closed), built on top of !135032 (merged).
Related merge requests
| Step | Merge Request | Description |
|---|---|---|
| 1 | !135032 (merged) | Adds the secrets push check, and puts it behind a feature flag. |
| 2 | This one. | Updates the secrets push check to check for license (only ultimate is allowed). |
| 3 | !135164 (merged) | Adds a new application setting for pre-receive SD, and updates the secrets push check accordingly. |
| 4 | !135273 (merged) | Adds the UI for toggling the application setting of pre-receive SD |
Why are making this an ultimate feature?
As part of the requirements, this feature is supposed to only work only for GitLab Ultimate.
Why is there a feature flag, a license check, and an application setting at the same time?
The license check is done to ensure pre-receive secret detection only works for GitLab Ultimate. As for the feature flag and the application setting, they are used because this feature is planned to work for GitLab Dedicated first, and then for other types of instances.
GitLab Dedicated, however, does not support feature flags, and since this is an experimental feature at the moment, the solution is to put the feature behind an application setting (introduced in step number 3) for dedicated instances, and for all other types to have the feature behind the same application setting and a feature flag enabled per project.
Please read more about this decision in this thread.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.