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

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

  1. In gdk rails console, label an existing failed job with the failure reason. An already-failed job is used because the drop state 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 }
  2. Open that job's page. Check the red alert below the job header.

  3. Select How do I fix it? and confirm it lands on the namespace does not have access to GitLab Secrets Manager troubleshooting heading, which now has GitLab.com and GitLab Self-Managed subsections.

Specs

bundle exec rspec spec/presenters/commit_status_presenter_spec.rb

61 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.

Edited by Chaya Danzinger

Merge request reports

Loading
Loading