Make secrets_manager_access_denied message environment-aware
What does this MR do and why?
Simplifies the secrets_manager_access_denied job failure message to a single, environment-independent string.
Previously this message branched on Gitlab.com? to show different remedies for GitLab.com versus GitLab Self-Managed. Review surfaced that the documentation lists five possible causes on GitLab.com and five on GitLab Self-Managed, and that the remedies actually available depend on license shape rather than distribution:
- An instance on a trial license is resolved as ineligible before CustomersDot is consulted, so it can never start a Secrets Manager trial.
- An offline (air-gapped) instance has no trial path and no on-demand billing path, because it cannot reach CustomersDot.
- Only an instance with a paid online license can start a trial.
A two-sentence banner cannot state remedies that hold across all of those cases, so the banner now states only the problem and the documentation carries the detail:
This job failed to retrieve secrets because it does not have access to GitLab Secrets Manager.
followed by the existing How do I fix it? link to the troubleshooting section. One message for every distribution.
As a result, CommitStatusPresenter#callout_failure_message is unchanged from the default branch — only the string in the CALLOUT_FAILURE_MESSAGES hash differs.
The troubleshooting entry for namespace does not have access to GitLab Secrets Manager in doc/ci/secrets/secrets_manager/_index.md now has two subsections, #### GitLab.com and #### GitLab Self-Managed, each listing its own causes and remedy. The GitLab.com remedy also links to the Secrets Manager usage and billing documentation, which covers credits and on-demand billing. That page's availability block covers GitLab.com only, so it is linked only from that subsection.
References
- Implements https://gitlab.com/gitlab-org/gitlab/-/work_items/616338
- Originating MR: !250292 (merged)
Screenshots or screen recordings
There is now a single message for all distributions, so one screenshot covers it: a red alert on the job page, below the job header and above the log, containing the failure message and the How do I fix it? documentation link.
Screenshot to follow.
How to set up and validate locally
-
In
gdk rails console, label an existing failed job with the failure reason. An already-failed job is used because thedropstate machine event only transitions from unfinished states, so a job that already succeeded cannot be dropped. Relabelling sidesteps the state machine and needs no runner and no pipeline:Ci::Build.where(status: 'failed').last.tap { |b| b.update!(failure_reason: :secrets_manager_access_denied); puts b.id } -
Open that job's page. Check the red alert below the job header.
-
Select How do I fix it? and confirm it lands on the
namespace does not have access to GitLab Secrets Managertroubleshooting heading, which now has GitLab.com and GitLab Self-Managed subsections.
Specs
bundle exec rspec spec/presenters/commit_status_presenter_spec.rb61 examples.
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.