ci: ask the release's version question on the pull request

[HuggeK]

The signed channel refuses to republish changed artifact bytes under a version it has already published — the rule that makes a version name a set of bytes an operator can pin. It was the one release check no pull request could run, because asking it needs the published channel, so it only ever ran from the release job on main.

That is how #53 merged with five green checks and took the release down with

error: nibe_local: changed artifact needs a higher version than 1.1.0

The repair (#55) then had to be a second pull request against a main that was already broken. This closes that window.

What runs now

A signed channel accepts this tree job on every pull request. It downloads the published drivers-beta manifest, rebuilds the artifacts in memory, and applies the release's rule.

Why this needs no secret, and works for forks

Nothing about the question involves signing. The published manifest is a public release asset; its signature verifies with FTW_DRIVER_SIGNING_PUBLIC_KEY, which is already sitting in plain text in the release workflow because it is a public key. The job signs nothing and reads no secret, so a pull request from a fork — which gets no secrets — runs it exactly like a branch pull request.

If drivers-beta has never been published, the job says so and passes: there are no versions to collide with.

The check has to agree with the release, or it is worse than nothing

_version_collisions is now the single statement of the rule. Both build_publication (while signing, on main) and check_publication (on a pull request) read it. A rule stated twice is a rule that drifts, and a preflight that drifts from the release gives false confidence.

test_check_versions_answers_what_the_release_would_answer pins that: same tree, same published manifest, both must reach the same verdict — pass and fail.

Verified against the live channel

Not just unit tests — I ran check_publication against the manifest the channel has actually published:

[main as published]  PASS -> {"published_commit": "7b8a18a…", "drivers": 80, "added": [], "changed": []}

[replay of #53: manifest-only ders edit, version left alone]  REFUSED ->
  the signed channel would refuse this tree:
    nibe_local: changed artifact needs a higher version than 1.1.1 (published)
      -- make bump-driver ID=nibe_local LEVEL=patch

The edit that broke main is caught before merge. test_check_versions_catches_a_manifest_only_edit is that same shape as a test: a manifest field corrected, no Lua touched, the published bytes moved anyway.

Other behaviour, and the tests for it

• Reports every colliding driver, each with the command that fixes it. The release still stops at the first — it has nothing else to do; someone fixing a branch wants the list (test_check_versions_reports_every_colliding_driver).
• A changed driver that took a version bump passes (test_check_versions_accepts_a_changed_driver_that_took_a_version).
• A driver the channel has never published is reported as added, not as a collision (test_check_versions_reports_a_driver_the_channel_has_never_published).
• A tampered manifest is still rejected — it is fetched over the network, so the signature has to hold (test_check_versions_rejects_a_manifest_the_signing_key_did_not_sign).

One sharp edge, stated in CONTRIBUTING

The comparison is against the published channel, not against main. So if main is itself unpublishable, this check fails on unrelated pull requests until main is fixed. That is the breakage surfacing rather than hiding, but it is worth knowing before it happens, so CONTRIBUTING.md says so — along with the command to ask the question locally, and the correction that this no longer fails only after a merge.

Test run

2969 passed locally. Fourteen failures are all pre-existing and reproduce on the unmodified base commit: ten need the lua55 interpreter the Makefile builds (plus one Windows path issue in test_blueprint.py), and four test_stable_promotion_* failures are a Windows CRLF artifact in manifest.payload.json. CI runs all of them on Linux.

tests/test_ftw_repository.py needs the package extra, which this machine does not have, so I ran it against an in-memory Ed25519 stand-in that keeps the properties the tests rely on — a signature verifies only under its own key, and any payload edit breaks it. Nothing about that stand-in is committed; CI runs the real thing.