Remove 'system failure' from the group secret expectation

John Masonrequested to merge
jmason-w133-qa-group-secret-system-failure into master

🤖 AI-authored change.

What does this MR do and why?

Removes one assertion from the group-level Secrets Manager end-to-end spec:

expect(trace).to have_content('ERROR: Job failed (system failure)')

gitlab-runner 19.4.0 no longer treats a failed CI secret resolution as a system failure. The trace now reads ERROR: Job failed: resolving secrets: getting secret: get secret data: reading from Vault: api error: status code 403. The runner only uses the (system failure) wording when the failure reason is RunnerSystemFailure (common/build.go#L1478), so the assertion can never pass again.

The cng-secrets-manager job fails on every run as a result. It became blocking when !255685 (merged) removed its allow_failure. As of 2026-09-16 19:48 UTC the tracking incident reported it blocking 48 pipelines.

Deleting the line is safe. The spec's contract is that a job whose secret cannot be resolved fails before running its script, and that is still asserted by the remaining expectations: the trace contains Resolving secrets and Resolving secret "NONEXISTENT_SECRET", and expect(trace).not_to have_content('This should not run'). Only the runner's internal classification of the failure is no longer pinned, and that classification belongs to the runner rather than to Secrets Manager behaviour.

This is the second half of a two-line fix. !255999 (merged) removed the identical line from the sibling project-level spec and has merged; the group-level spec was missed, so the job is still red.

Verification: the file is syntax-checked only (ruby -c passes). This is a live end-to-end spec that needs a running CNG environment with a Secrets Manager licence, so it was not run locally.

References

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.

🤖 Automated change — mention me to get a response. Feedback welcome. Ask to speak to John directly anytime.

Edited by John Mason

Merge request reports