Create a push check for secret detection
What does this MR do and why?
This merge request introduces a placeholder push check to be used for detecting secrets in every new git-push.
Note: we broke down the work in &11613 (closed) to as small as possible iterations, so the focus here is not on the functionality of the push check itself but rather on having it in the correct place and behind the correct feature flag, which we also created here under the name:
pre_receive_secret_detection_push_check
Resolves #427039 (closed).
Related merge requests
| Step | Merge Request | Description |
|---|---|---|
| 1 | This one. | Adds the secrets push check, and puts it behind a feature flag. |
| 2 | !135036 (merged) | 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 we introducing a feature flag and an application setting at the same time?
In the related merge requests (as shown above), we introduce an application setting (configurable via the UI) in addition to the feature flag introduced in this merge request, the reason is because this feature is planned 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.