Expose the Orbit trial offer on OrbitTrial

What does this MR do and why?

CustomersDot now sends the default trial offer (days and free credits) with the trial status. This MR adds it to OrbitTrial as offer, so the Orbit pages show the real trial terms instead of numbers written in the frontend.

  • New experiment field OrbitTrial.offer { durationDays initialCredits }.
  • The field is null unless the group can start a trial. An active or ended trial can have other terms.
  • The field is null when CustomersDot does not send two positive values, or sends an offer of the wrong shape. The rest of the trial still loads.
  • It reads the response that orbitTrial already gets, so there is no new CustomersDot call and no cache change.

References

Screenshots or screen recordings

No UI change. The frontend MR stacked on this one shows the field in use: !261364 (merged)

Response from a local GDK with a local CustomersDot on the production SHA
{
  "data": {
    "group": {
      "orbitTrial": {
        "state": "ELIGIBLE",
        "expiresOn": null,
        "credits": { "remaining": 0.0, "total": null },
        "offer": { "durationDays": 30, "initialCredits": 100.0 }
      }
    }
  }
}

How to set up and validate locally

  1. Point the GDK at a CustomersDot that has the change above (see the CustomersDot local setup), with GITLAB_SIMULATE_SAAS=1.

  2. As an Owner of a top-level group in the Orbit trial flow, run this query in GraphiQL:

    { group(fullPath: "<group>") { orbitTrial { state offer { durationDays initialCredits } } } }
  3. For a group that can start a trial, offer shows the days and credits that CustomersDot sends. For an active, ended, or not eligible trial, offer is null.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Jean-Gabriel Doyon

Merge request reports

Loading
Loading