Verify the release package on a runtime the release runner can execute - #10
Merged
Conversation
The publish job checks that a fresh consumer can install and run the packages before it pushes them, and it asked for linux-x64. That was right while the job ran on ubuntu. It moved to macOS in 8597427, so that the iOS workload could be installed at all - there is no Linux host pack for it - and this step did not move with it. verify-package.ps1 does not merely restore the package. It publishes a consumer and runs a simulation through it, so the runtime identifier has to be one the runner can execute. Building an ELF binary on a Mac and starting it gets: Program 'consumer' failed to run ... Exec format error which is what v0.4.0's first attempt died on. Nothing had been pushed, because this step runs before the push - that ordering is the reason the failure cost nothing but a re-tag. osx-arm64 is the host's own identifier. CI covers the other five against the same packed .nupkg on runners that can run them; what this step adds is that the exact files about to become permanent were installed and executed once more, and it can only do that for this machine. Worth noting where this hid: release.yml runs on a tag and nothing else, so a break in it survives any number of green CI runs and surfaces at the one moment it is most expensive. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
v0.4.0's release run failed, before the push. Nothing reached nuget.org —0.1.0, 0.2.0 and 0.3.0 are still all that is there, and no GitHub release
object was created either, because both of those steps come after the one that
failed.
What broke. The
publishjob verifies that a fresh consumer can install andrun the packages before pushing them, and it asked for
linux-x64. That wascorrect while the job ran on
ubuntu-latest.8597427moved it to macOS so theiOS workload could be installed — there is no Linux host pack for it — and this
step stayed behind.
verify-package.ps1publishes a consumer and runs asimulation through it, so the RID has to be one the runner can execute:
a perfectly good ELF binary, built on a Mac.
Not the runner migration.
v0.3.0published fromubuntu-latestwith thissame line, and #9 only changed
macos-14tomacos-15. The break arrived withthe mobile PR and was invisible for two days because
release.ymlruns on a tagand nothing else — a break in it survives any number of green CI runs and
surfaces at the one moment it is most expensive.
The fix is
osx-arm64, the host's own identifier. CI already covers theother five against the same packed
.nupkgon runners that can run them; whatthis step adds is that the exact files about to become permanent were installed
and executed once more, which it can only do for this machine.
After this merges,
v0.4.0gets deleted and re-pushed. The tag publishednothing and has no release attached, so there is nothing to supersede.
🤖 Generated with Claude Code