[erikdarlingdata]

Found while building a 3.5.1 release candidate to soak before tagging: I dispatched nightly.yml onto release/3.5.1 and got artifacts built from dev.

check      ref: dev          <- hardcoded
build      ref: dev          <- hardcoded  (builds + publishes the artifacts)
darling-pg ref: <dispatched> <- correct
linux      ref: dev          <- hardcoded

So the run tested release/3.5.1 and shipped dev.

The reason this is worth more than a one-line fix: nothing that would normally confirm what you built disagrees. The run's head SHA, the API, and the Actions UI all report release/3.5.1, because that genuinely is what was dispatched — only the checkout went elsewhere. I verified the head SHA matched the branch tip and that it contained #2388/#2390/#2397, and every one of those checks passed while the artifact was still dev.

What actually gave it away was the asset name: PerformanceMonitorDarling-3.5.0-nightly.20260821.zip on a branch whose Lite/PerformanceMonitorLite.csproj says 3.5.1. Both version steps read that file, so the stamped version is a direct readout of which tree was checked out — visible only if you read the filename and know what to expect.

The workflow's own comment already stated the intent:

Everything below runs only in a workflow_dispatch run — the scheduled re-dispatch or a manual one — which executes from the dispatched ref (dev for the scheduled path).

so the pins contradicted the documented design rather than expressing it. All four checkouts now resolve identically, falling back to dev for the scheduled path — which re-dispatches with --ref dev regardless.

[claude]

Reviewed. The fix itself is correct and minimal: all four checkouts (check, build, linux, and the pre-existing darling-pg) now resolve ${{ github.event_name == 'workflow_dispatch' && github.ref_name || 'dev' }} consistently, matching the pattern darling-pg already used. Since check/build/linux are all gated (directly or transitively via needs: check) on github.event_name == 'workflow_dispatch', the 'dev' fallback is inert during workflow_dispatch runs and only matters if these jobs were ever reached another way — harmless as written.

One loose end worth fixing while this file is open: .github/workflows/nightly.yml:271-274, the comment on the darling-pg checkout step, is now stale and self-contradicting:

the artifact-publishing build job stays pinned to dev either way, so a branch dispatch can never ship branch binaries

That described the old, buggy behavior. After this PR, build's checkout (line 101) resolves the dispatched ref exactly like darling-pg does — a branch dispatch can now ship branch binaries from build, which is the entire point of this fix. Left uncorrected, a future reader could read that comment as documenting intended design and "fix" build back to ref: dev, reintroducing this exact bug. (I couldn't leave an inline comment there since those lines are outside the diff hunk — flagging here instead.)

No T-SQL, no Lite/Darling app-code touched, so the style guide and parity concerns don't apply to this change.