Use different FF in shared runners limit check
What does this MR do?
In the !27792 (merged), we have a minor issue with our two feature flags.
The idea was to enable the first flag (ci_minutes_track_for_public_projects
) and start accumulating the minutes for public projects without putting any restrictions/limiting (so we could test the numbers and also the pressure on background jobs if needed) while the second feature flag (ci_minutes_enforce_quota_for_public_projects
) would force the limits.
The issue:
UpdateBuildMinutesService
currently does return unless build.shared_runners_minutes_limit_enabled?
which is implemented as ::Feature.enabled?(:ci_minutes_enforce_quota_for_public_projects)
(second feature flag).
So, with the current implementation, enabling just the first feature flag will not accumulate minutes for public
. We need them both to even track the minutes which is not what we want. So we're fixing it.
We update implementations of def shared_runners_minutes_limit_enabled?
in project
and build
to rely on the ci_minutes_track_for_public_projects
for the given namespace instead ci_minutes_enforce_quota_for_public_projects
.
The only minor downside of such change that we won't change :with_shared_runners_limit_enabled
scope (it would rely on the second flag), which is slightly inconsistent, but I think this should be fine.
Does this MR meet the acceptance criteria?
Conformity
- [-] 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
Security
N/A
Relates to #210570 (closed)