Skip to content

Store future subscriptions on instance activation

What does this MR do and why?

Part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3651+

Depends on https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5502+ to be merged first

Prior to this change, when activating an instance and a renewal was already done for the subscription linked to the activation code, the information about the renewal was only known on the next subscription details sync. A banner when the subscription is about to expire was still displayed before that sync.

Now, when activating in this scenario, the future subscriptions will also be synced directly and will be displayed in the subscription history table. A banner will not be displayed anymore due to knowing about the future subscription.

Screenshots or screen recordings

How to set up and validate locally

  1. Purchase a self-managed subscription that is ending in 3 days and keep the activation code handy.
  2. Renew the subscription in your CustomersDot instance at http://localhost:5000//subscriptions/<subscription_name>/renew.
  3. Use activation code to activate your local GitLab instance at http://gdk.test:3000/admin/subscription.
  4. Verify there is no expiration banner displayed.
  5. Verify there are two new entries in the subscription history table at the bottom of the subscription page. One for the current term (ending in 3 days) and one for the future term (= the renewal term).

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Corinna Gogolok

Merge request reports