ci: add build-migration-progress workflow#442
Closed
mrosseel wants to merge 1 commit into
Closed
Conversation
Cross-compiles python/scripts/migration_progress.c for aarch64 on a v*-migration tag push (or manual workflow_dispatch against an existing tag) and attaches the stripped static binary + its SHA256 sidecar to the matching release. Companion to PR brickbots#433 (NixOS migration infrastructure): that PR removed the pre-compiled migration_progress blob from the source tree and now expects nixos_migration.sh to download + verify it at runtime. This workflow is what produces those release assets. Landing the workflow file separately so workflow_dispatch is usable before brickbots#433 itself merges — GitHub Actions requires the workflow file on the default branch to expose it for manual dispatch. migration_progress.c isn't on main yet, so the workflow sits inert until brickbots#433 lands (or a v*-migration tag is created from the migration branch in the meantime).
Collaborator
Author
|
Closing — overengineering for a one-shot binary used by one migration release. The binary stays committed alongside its .c source in #433 so reviewers audit both in the same diff. Reproducibility is provided by git content-addressing the same .c that produces the blob. |
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
1 participant
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.
Summary
Adds
.github/workflows/build-migration-progress.yml: on av*-migrationtag push (or manualworkflow_dispatchagainst an existing tag), cross-compilespython/scripts/migration_progress.cfor aarch64 (-static -O2, stripped) and attaches the binary + its SHA256 sidecar to the matching release.Why land this separately from #433?
This workflow is the producer side of a change in #433: that PR drops the pre-compiled
migration_progressELF from the source tree and expectsnixos_migration.shto download + verify it from the release at migration time. The two changes are independent enough to review separately, and there's a practical reason to land this one first:workflow_dispatchrequires the workflow file to exist on the default branch to be triggerable. Until this file is onmain, no one can manually rebuild the artifact for an existingv*-migrationrelease tag. Landing this PR makes the dispatcher available even before #433 itself merges.Caveat
migration_progress.cdoesn't yet exist onmain— it arrives with #433. Until then this workflow is inert (its build step would fail with "no such file" if dispatched againstmain). The intended sequence is: this PR merges first → #433 merges → CI rebuilds the binary on the next migration tag.Test plan
release_tag=v2.5.0-migrationinput from a branch that does havemigration_progress.c(e.g. themigrationbranch on the fork) — verify the binary lands in the release with the expected SHA256.