Skip to content

Expire Ci::Minutes::CachedQuota when minutes limits are updated

What does this MR do?

Related to https://gitlab.com/gitlab-org/gitlab/-/issues/20856

This MR is based on top of !59263 (merged) where we implemented a mechanism to track CI minutes consumption while jobs are running. Because in that case we cache the remaining minutes in Redis (for performance reasons), there are scenarios where suddenly the remaining minutes can drastically change:

  1. on the first of the month we reset the CI minutes consumption to 0
  2. admin user (e.g. Tech Support) can reset the CI minutes consumption on behalf of the customer
  3. the customer can change plan - CustomersDot portal will update the namespace shared_runners_minutes_limit
  4. the customer purchases additional minutes - CustomersDot portal will update the namespace extra_shared_runners_minutes_limit

For (1) we have solved the problem by having Gitlab::Ci::Minutes::CachedQuota using the current year-month in the key. On the first of the month, the key would automatically expire.

For the remaining (2), (3) and (4) we solve it in this MR by expiring the cache explicitly.

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

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 @gitlab-com/gl-security/appsec
  • 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

Merge request reports

Loading