ci: let a Windows retry build a ref other than the release tag

[jqnatividad]

Why Windows could not publish

publish-target.yml takes its workflow YAML from the ref that triggered the run, but
checks out previous_tag for the source. A CI fix written in the matrix therefore takes
effect on a retry, while the identical fix written in Cargo.toml is silently reverted by
the tag checkout.

That asymmetry is why 22.0.1 shipped no Windows binaries:

binary	where its viz_static removal lives	effect on a retry
qsv	addl-build-args in the matrix	applied → built fine (52m / 97m PGO)
qsvmcp	the qsvmcp feature in Cargo.toml	reverted → never finished, in any run

qsvmcp gained viz_static in 2f83bcd (viz, #4019). 21.1.0 — the last release whose
qsvmcp had no viz_static — shipped Windows binaries; 22.0.1 did not, across three
capped runs (31243109948, 31261021249, 31287336214), each ≥218m with Build qsvmcp never
completing once.

A consequence worth flagging: every earlier attempt to explain the qsvmcp build time
(crate counts, polars feature counts, LOC) was measured against master's Cargo.toml,
and so described a build CI never performed.

Proof

Run 31303175743 — success.

job	total	steps
msvc [main]	107m	qsv PGO 97m, qsvlite 9m
msvc [mcp]	46m	qsvmcp 46m
gnu [main]	61m	qsv 52m, qsvlite 8m
gnu [mcp]	47m	qsvmcp 47m
[package] ×2	3m / 4m

Build qsvmcp went from ≥268m-and-never-finishing to under 47 minutes. Both zips are
now on the 22.0.1 release (msvc 142.0 MB, gnu 118.7 MB), each verified to contain
qsv.exe, qsvlite.exe, qsvmcp.exe and the license/notice files. The six pre-existing
release assets kept their original timestamps.

What this changes

• publish-target.yml: new optional source_ref. Empty (the default) builds
  previous_tag, so publish.yml — the real release path — is unchanged. Used by the
  build and package jobs alike, so the shipped THIRD_PARTY_NOTICES.md and per-target
  README keep describing the binaries beside them.
• publish-windows.yml: defaults source_ref to the dispatched commit, pinned to the
  SHA so a mid-run push cannot change what is built. This is the opposite of publish.yml
  and deliberate — this workflow only runs after a Windows publish has already failed,
  which is exactly when the fix is on master and not in the tag.
• Release-tag guard. This workflow is dispatched from an untagged master, so tag
  auto-detection is not exercised the way publish.yml exercises it; the repo carries a
  non-version tag (git tag --sort=-version:refname | head -1 returns rkyv); and the
  upload runs with overwrite: true. The guard asserts MAJOR.MINOR.PATCH and that the
  release exists, with a release_tag input to override. It logged
  override='' detected='22.0.1' -> resolved='22.0.1'.

The next release will not need source_ref — master's Cargo.toml already has
qsvmcp without viz_static, so a new tag carries the fix. This is a retry escape hatch,
not a new default.

Provenance

The shipped Windows 22.0.1 assets were built from 2a0feb607 on this branch, not
from the 22.0.1 tag. Recorded here so the source stays findable if the branch is deleted.
qsv --version still reports 22.0.1: the string comes from CARGO_PKG_VERSION
(util.rs:140/:284), and Cargo.toml's version is unchanged on this branch.
Self-update detection is intact — util.rs:1623 gates on QSV_KIND.starts_with("prebuilt"),
satisfied by both prebuilt and the PGO step's prebuilt-pgo.

Note on the commit message

The commit body carries a 3-row table including 22.0.0 / viz_static / no Windows assets.
There is no release object for 22.0.0 (tag only), so that row is literally true but
misleading as evidence — it shipped nothing at all, for unrelated reasons. The claim rests
on the 21.1.0-vs-22.0.1 contrast and, more directly, on the ≥268m → 46m before/after above.

Follow-ups (not in this PR)

• feat(qsvmcp)!: drop get and get_cloud from the qsvmcp build #4374 (breaking: drop get/get_cloud from qsvmcp) was adopted for a build-time
  problem it did not cause; measured impact was 2 crates. Worth revisiting on its own merits.
• ci: raise the Windows publish cap 270 -> 330 #4369 (cap 270 → 330) is now unnecessary — the slowest job is 107m.
• ci: thin LTO + 16 codegen units + Defender exclusions for Windows publish #4373's lto: thin + codegen-units: 16 should not be reverted casually: they are
  the settings these successful builds ran under, and fat LTO + codegen-units=1 has never
  completed for qsvmcp on Windows.
• cargo-timings-* artifacts for all four legs are attached to the run (14-day retention) —
  the first real Windows build-time data.

Validated with actionlint (0 findings) and scripts/check-publish-matrix-sync.py (OK).

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}