Loading
Backport the Orbit trial credit grants fix to 19.5
What does this MR do and why?
Backport of the GitLab Orbit fix that merged to master after the daily backport of the day, and is not on 19-5-stable-ee yet. Each MR is one git cherry-pick -m 1 -x. The code and spec lines are the same as in the original MR. The only conflict is in the generated GraphQL docs: 19-5-stable-ee keeps them in experimental/objects.md and _index.md, so the one changed description line goes there. The branch is squashed into one commit.
| # | MR | Change | Author | Merged | Type |
|---|---|---|---|---|---|
| 1 | Sum all credit grants of an Orbit trial (!265126 - merged) | Sum all credit grants of an Orbit trial | jgdoyon1 |
2026-10-26 18:04 UTC | typebug |
How the MRs were selected
- Sweep of all
into 'master'merges since the 19.5 base, after the 2026-10-26 daily backports !265147 (merged) (19.5) and !265148 (merged) (19.4): labelgroup::context-systems, Orbit authors, and files or diff lines that matchorbit|knowledge_graph. - Kept: Orbit code, and shared code that Orbit cannot work without.
- Already on
19-5-stable-ee: the GA backport !263724 (merged) and the daily backports up to !265147 (merged), which has the other Orbit MRs of today. - Endpoints get their own backport MR: none in this MR.
- Not needed:
- Today's other Orbit MRs (!264917 (merged), !264873 (merged), !264924 (merged), !264923 (merged), !265010 (merged)) are in Dmitry's daily backports !265147 (merged) and !265148 (merged).
Verification
git patch-id --stableof the code and spec changes (ee/,public/) is the same as the one of the original merge commit. Only the generated docs differ.- Local, on the
19-5-stable-eedependencies: RSpec and RuboCop on the changed files (no frontend files) (results in a comment). - MR pipeline at
pipeline::tier-3.
Points for reviewers:
- The original MR is
type::bug. The MR hastype::maintenancefor thestable_branch.rbDanger rule, as the GA backports had. It needs a release manager exception (ask in#releases). - Bug fix: the Orbit trial uses only the credit grants of the current trial (the grants with the latest expiry) for its credit total, dates, and state. Only the CustomersDot trial parser changes; the Secrets Manager parser does not.
- No migrations, no feature flags.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
- This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch. (Release manager exception requested.)
- The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
- The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
- Required labels have been applied to this merge request
- severity label and bug subtype labels (if applicable)
- If this MR fixes a bug that affects customers, the customer label has been applied.
- This MR has been approved by a maintainer (only one approval is required).
- Ensure the
E2E Omnibus GitLab EEpipeline (triggered by thee2e:test-on-omnibus-eejob) has succeeded. If it has failed (or shows warnings), investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, request help in the #s_developer_experience Slack channel to confirm the failures are unrelated to the merge request.
Note to the merge request author and maintainer
If you have questions about the patch release process, please:
- Refer to the patch release runbook for engineers and maintainers for guidance.
- Ask questions on the
#releasesSlack channel (internal only). - Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.