fix(ci): unblock image job on private-repo SARIF upload

[devin-ai-integration]

Summary

The post-merge main build of #10 (commit db7fcb5) successfully built, pushed, and Cosign-signed ghcr.io/bcit-tlu/haproxy-operator/haproxy-operator:0.2.1-head.db7fcb5, but the final github/codeql-action/upload-sarif@v4 step failed with:

Resource not accessible by integration - https://docs.github.com/rest/actions/workflow-runs#get-a-workflow-run

Because the image job failed, the downstream helm-publish job (needs: [image, versions]) was skipped, so the chart was not published and the first-ever haproxy-operator/charts/haproxy-operator GHCR package still doesn't exist.

Root cause: on private repos, codeql-action/upload-sarif fetches the calling workflow run's metadata from /actions/runs/{run_id} which requires actions: read. Public repos (hriv, tech-ops-docs) don't hit this path because that endpoint is anonymous for public repos — which is why their post-merge unified-versioning builds both published cleanly.

Two-part fix:

1. Add actions: read to the workflow-level permissions: block so the required metadata fetch actually works.
2. Mark the upload step continue-on-error: true so a transient telemetry-upload failure never cascades into blocking chart publication of an already-built, already-signed image. The Security tab upload is a diagnostic sidecar — publish-gate is already defended by the MODE guards on build/push/sign, which are the artifact-correctness path.

Review & Testing Checklist for Human

• After merging, watch the post-merge main CI run — expect image + helm-publish both green, and the first unified chart artifact 0.2.1-head.<sha> (+ head moving tag) to land at ghcr.io/bcit-tlu/haproxy-operator/charts/haproxy-operator.
• Verify Trivy SARIF results still appear in GitHub Security → Code scanning alerts (confirms actions: read did what we expect).
• After this lands, open the flux-fleet follow-up to flip apps/haproxy-operator/base/ocirepository.yaml from ref.tag: latest to ref.tag: head (noted as pending in the Apr 2026 strict-D adoption).

Notes

Not propagating this fix to hriv or tech-ops-docs — they're both public and their post-merge unified builds already succeeded (hriv 0.6.0-head.40b2888, tech-ops-docs 0.2.1-head.28e2ad8), so there's no evidence the private-repo code path is exercised there. Adding actions: read to those preemptively would be harmless but violates minimum-scope; happy to propagate if you'd prefer symmetric permissions across the three repos.

Link to Devin session: https://app.devin.ai/sessions/a5e23b4cc3a34f4caa54267af3c1ccc4
Requested by: @kphunter

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.

[devin-ai-integration]

📝 Info: continue-on-error silently swallows all upload-sarif failures

Adding continue-on-error: true at line 255 means that any failure of the SARIF upload — including persistent misconfiguration (wrong permissions, bad SARIF format, etc.) — will be reduced to a workflow warning rather than a failure. The follow-up step at line 260-263 does emit a ::warning, which is good, but warnings are easy to miss in GitHub Actions UI. If the SARIF upload is broken for an extended period (e.g., a permissions regression), the team may not notice that vulnerability scan results are silently not reaching the Security tab. Consider whether a periodic audit or a separate alerting mechanism is warranted.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Good catch — the review correctly points out that continue-on-error: true is too broad as written. Addressed in a1830cd:

• Added an id: upload-sarif handle on the codeql-action step.
• Added a follow-up step guarded by if: steps.upload-sarif.outcome == 'failure' that emits a ::warning:: annotation.

Net effect: a failed SARIF upload still doesn't block the pipeline (preserves the original unblock intent), but it now surfaces as a yellow warning annotation in the workflow summary instead of silently disappearing. This covers the regression scenarios you enumerated (malformed SARIF, removed security-events: write, CodeQL breaking changes) — each would show up as a visible warning on the run.

[devin-ai-integration]

Agreed that a persistent warning can get buried if nobody watches the runs — but I think that's a monitoring/alerting concern separate from this workflow change, not something to block the PR on. Concretely:

• The GitHub Security tab itself is the primary signal: if it stops gaining new scan timestamps, that's the canonical "alert". Anyone looking at https://github.com/bcit-tlu/haproxy-operator/security/code-scanning will see stale data immediately.
• The right place for an "extended-period SARIF upload broken" alarm is a Vault/Grafana-style cross-repo audit (e.g. a scheduled workflow that lists repos + checks last CodeQL analysis date), not inside each per-repo pipeline.
• The ::warning:: annotation plus the image job going green is the correct local contract: publish artifacts are decoupled from telemetry upload, but telemetry failures are not invisible on the run that produced them.

Happy to file a follow-up issue to track the cross-repo audit idea if that's useful, but not going to add it inline here.