BUILD-11571: Clarify SCA Check failures that are due to vault auth

[bwalsh434]

Summary

Rework the check-sca failure output to be concise and actionable, centered on the most common fix: grant the repo access to the SonarQube secrets via the Manage Vault Policy SPEED action.

• Vault access missing (no Vault role): the summary explains the repo can't read the SonarQube secrets and links directly to the Manage Vault Policy SPEED action in Port — prefilled with the repo as $targetEntity and ignore_secrets=true (auth-only) — then says to re-run.
• No SCA data failure: leads with the same prefilled SPEED action link (missing Vault access is the most common cause), with a one-line fallback noting the project may not be analyzed yet or check-sca.project-key may not match — pointing to the Verify SCA ran step logs for the per-platform diagnosis.
• The Port deep link is built once in a shared step and reused by both summaries.
• Links to the SCA Scanning Checks FAQ for full details; the error annotation was shortened to match.

Test Plan

• Test on a PR that will fail the SCA Check, having it reference this branch directly, and confirm the message is much more readable.
• Also confirm that the link to SPEED works as expected, with the prompt already filled out!

[hashicorp-vault-sonar-prod]

BUILD-11571

[bwalsh434]

gitar fix pre commit check (CI)

[gitar-bot]

gitar fix pre commit check (CI)

The pre-commit failure was yamllint reporting [quoted-strings] string value is redundantly quoted with single quotes at lines 83 and 127 of check-sca/action.yml. The .yamllint.yaml config requires quote-type: single and required: only-when-needed, so the double-quoted FAQ URL values were violating both rules (URL strings need no quoting in YAML). Removed the surrounding double quotes from both FAQ env var values.

[Copilot]

Pull request overview

Updates the check-sca composite action’s failure/success workflow summaries to provide clearer, more actionable guidance when SCA cannot be verified—especially when Vault authentication/authorization prevents reading SonarQube credentials.

Changes:

• Adds a step that constructs a deep link to Port’s Manage Vault Policy self-service action (prefilled with repo + current week).
• Improves the “missing Vault access” failure path to point directly to the Port action and the SCA checks FAQ.
• Enhances the general workflow summary messaging when SCA verification fails (adds Vault-policy guidance + project key/analyzed-yet hint).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Enhanced SCA failure messaging with direct links to the Manage Vault Policy action, resolving the incorrect attribution of failures to Vault access. The output is now more concise and actionable for troubleshooting authentication or configuration issues.

✅ 2 resolved

✅ Bug: Generate-summary failure text wrongly blames Vault access

📄 check-sca/action.yml:121-135
In the Generate workflow summary step (lines 119-145), the failure branch now says: "Most often the repo isn't allowed to read the SonarQube secrets from Vault. Fix: run the [Manage Vault Policy SPEED action]...". However, this step only runs when steps.vault-fail.outcome != 'failure', and vault-fail only fires when steps.secrets.outcome == 'failure'. The Verify SCA ran (check) step that sets sca-verified only runs when steps.secrets.outcome == 'success'. Therefore, whenever this summary's else branch is reached, Vault authentication has already succeeded — a Vault-access failure would have been caught by the vault-fail step (which exits 1 and suppresses this summary).

The result is that a real SCA failure (project not analyzed yet, wrong check-sca.project-key, SCA not enabled, slow analysis) is reported with Vault access as the primary, "most common" cause and steers the developer to the Manage Vault Policy action, which cannot fix the problem in this code path. The previous wording correctly led with "no SCA data was found" and listed the actual likely causes. Recommend leading with the analysis/project-key causes (as before) and demoting or removing the Vault-access explanation in this branch, since Vault auth is guaranteed to have succeeded here.

✅ Edge Case: WEEK uses %Y_%V which mismatches ISO week-year at year boundaries

📄 check-sca/action.yml:77 📄 check-sca/action.yml:80
WEEK="$(date -u +%Y_%V)" pairs the Gregorian year (%Y) with the ISO-8601 week number (%V). These two diverge around New Year: e.g. 2027-01-01 belongs to ISO week 53 of 2026, so %Y_%V yields 2027_53 (a week that doesn't exist) instead of 2026_53; likewise late-December dates can produce YYYY_01 of the wrong year. The correct pairing for %V is the ISO year %G (i.e. +%G_%V). The result is that, during a handful of days each year, the prefilled current_week in the Port deep link will be wrong/invalid.

Note: the inline comment states this intentionally mirrors the Port action's default (now | strftime("%Y_%V")). If the upstream action genuinely uses %Y_%V, then "fixing" only this side would introduce a mismatch — so confirm the upstream encoding before changing. If upstream is also %Y_%V, consider fixing both. Impact is limited to the informational prefill of a self-service form, hence minor.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud