ci(code_quality): Qodana scan fails so upload-sarif is skipped — SARIF has never actually been uploaded

[kploch]

Problem

.github/workflows/code_quality.yml has never successfully uploaded SARIF. On its only recorded run, step 3 Qodana Scan failed and step 4 upload-sarif was skipped — the upload step has no if: always(), so it never executes when the scan fails.

That has two consequences:

1. Code scanning has no data from this workflow. The scan result never reaches GitHub.
2. The action version is unvalidatable. Both the outgoing v3.28.18 pin and the incoming v4.37.8 pin (PR chore(deps): bump github/codeql-action/upload-sarif from 3.28.18 to 4.37.8 #132) are equally unexercised — the last recorded run used actions/checkout@v3 and upload-sarif@v2, predating both. There is no baseline behaviour to regress from.

This makes "verify after merging #132 with one manual dispatch" inconclusive rather than merely imprecise: a post-merge dispatch that fails at Qodana again will skip the upload step again and produce zero evidence.

Suggested fix

Two independent changes, both worth making:

• Fix the Qodana step so the scan itself succeeds. Candidates: the QODANA_TOKEN_1681345019 secret wiring (corrected in ci: Pin actions to SHAs, use sonar.token, justify continue-on-error #125) and the --baseline,./qodana.sarif.json argument, which points at a file that may not exist on a first run.
• Add if: always() to the upload-sarif step so a failed scan still uploads whatever SARIF was produced, and the step's own behaviour becomes observable.

The loop only closes when upload-sarif has actually run to completion at least once. Until then, treat the codeql-action version in this workflow as unverified regardless of how many times it is dispatched.

Also worth knowing

• 4.37.8 is already superseded — the upstream CHANGELOG records 4.37.9 (26 Aug 2026), so merging chore(deps): bump github/codeql-action/upload-sarif from 3.28.18 to 4.37.8 #132 will be followed by another Dependabot PR for the same action shortly. Non-blocking.
• The node24 runtime in codeql-action v4 is fine for us — every job in this workflow uses runs-on: ubuntu-latest. It would be a hard break on a self-hosted runner older than 2.327.x, worth remembering if this workflow ever moves off GitHub-hosted runners.
• Dependabot's diff also strips the UTF-8 BOM from line 1 of the file. Harmless (YAML 1.2 permits a leading BOM and Actions parses both), but it means the PR touches a line unrelated to the dependency.

Context

Found during an adversarial review of Dependabot PR #132. Independently confirmed: the upload-sarif action interface is unchanged across the bump (zero inputs removed, renamed, or re-defaulted), and the repo passes only sarif_file, which is untouched. The bump itself is safe; the problem is that nothing here is being validated at all.

Refs #132, #93

[kploch]

PR #147 fixes every configuration defect this issue names, but cannot close it, and there is now direct evidence of why.

Dispatch 33428446669 on ci/138-workflow-hardening-and-secrets is the first Qodana run in this repository ever to get past solution loading. It failed on a licence check that runs before the solution is opened:

Your Qodana Cloud organization has Community license that doesn't support "Qodana for .NET"
linter, please try one of the community linters instead

No SARIF can be produced under any configuration while that stands, so this issue's own criterion — "the loop only closes when upload-sarif has actually run to completion at least once" — is unreachable from a workflow file. Split out to #151.

What #147 did fix, all confirmed against real runs rather than reasoning:

• qodana.yaml pointed at Ploch.Common.sln, which has never existed here → now Ploch.Data.slnx.
• exclude.paths takes plain directory paths, not globs → tests, samples, DocumentationSite.
• Neither sibling repository was cloned → both are, with ploch-common at full depth because it is built and NBGV cannot compute commit height from a shallow clone.
• The clones landed outside the directory Qodana bind-mounts, making them invisible to the analysis container → both are now mounted at /data/<name>, confirmed reaching the CLI verbatim in the run log.
• QODANA_NUGET_* credentials added for the authenticated GitHub Packages feed that SampleApp's Ploch.* references are source-mapped to.
• timeout-minutes: 15 was below the measured build time, and a timeout cancels the job, which skips if: always() steps — it would have silently defeated the observability this issue asked for. Raised to 60.
• SARIF upload gated on the file existing, so an early failure warns instead of erroring on a missing file.

The observability half of this issue is working and demonstrated. Across both dispatches the job finishes green, emits No SARIF produced, skips the upload cleanly, and surfaces the scan outcome as an annotation — instead of the previous behaviour where the job aborted at the scan and nothing was ever reported. That is what made the licence failure visible at all.

Leaving this issue open, referenced rather than closed by #147.

[kploch]

Update: the licence block tracked in #151 is now resolved by PR #190 (switched to the Community .NET linter, two confirmed green dispatches). That PR also removes the github/codeql-action/upload-sarif step this issue was originally about — Qodana now reports directly to Qodana Cloud via QODANA_TOKEN instead of GitHub code scanning, which is what ploch-common's already-working workflow does too, and is also what caused the project to register on qodana.cloud (it previously showed "not configured" because no scan had ever completed). If a GitHub code-scanning upload is still wanted in addition to Qodana Cloud, that's a separate follow-up — upload-sarif needs ref/sha passed explicitly to fix the "GITHUB_REF environment variable must be set" error hit along the way.