fix(action): accept from-version input on publish-ghcr - #41
Merged
Conversation
Closes #40. The publish-ghcr mode re-derived the previous version from the registry independently of the generate-ghcr step that actually downloaded the source binary and ran bsdiff. If the registry state changed between the two steps (concurrent push, semver re-ordering with a cross-major nightly), the two values could disagree and `binpatch` consumers would silently hit SHA mismatch (the library only verifies the final output SHA, not the source binary identity — the annotation is a chain pointer, not a content hash). Add a new `from-version` input on publish-ghcr. When set, the annotation on the pushed patch manifest uses THIS value verbatim. When empty (back-compat), the old registry re-derive runs and prints a hint suggesting the caller thread the value from generate-ghcr. The consumer-side wiring change is trivial: ```yaml - uses: BYK/binpatch/action@vX.Y.Z id: gen with: { mode: generate-ghcr, ... } - uses: BYK/binpatch/action@vX.Y.Z with: mode: publish-ghcr from-version: ${{ steps.gen.outputs.from-version }} ``` Files: - action/action.yml: add `from-version` input, thread to push_patches via env, use input when set else re-derive - action/README.md: document the new input and the gen→publish wiring
Contributor
|
BYK
added a commit
that referenced
this pull request
Aug 1, 2026
The 0.4.0 release was cut on the `release/0.4.0` branch but that branch was never merged back to `main`. The 0.4.0 git tag points at a commit (`d5e8341`) that is NOT reachable from current main, which breaks Craft's auto-versioning (it relies on `git describe` walking back from HEAD to find the most recent release tag). The next release workflow run after this fix should produce 0.4.1 (one new commit since 0.4.0: the from-version input fix from PR #41).
This was referenced Aug 1, 2026
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.
Closes #40. The
publish-ghcrmode re-derived the previous version from the registry independently of thegenerate-ghcrstep that actually downloaded the source binary and ran bsdiff. If the registry state changed between the two steps, the two values could disagree andbinpatchconsumers would silently hit SHA mismatch (the library only verifies the final output SHA, not the source binary identity — the annotation is a chain pointer, not a content hash).Fix
Add a new
from-versioninput onpublish-ghcr. When set, the annotation on the pushed patch manifest uses THIS value verbatim. When empty (back-compat), the old registry re-derive runs and prints a hint suggesting the caller thread the value fromgenerate-ghcr.Consumer wiring
Files
from-versioninput, thread to push_patches via env, use input when set else re-deriveRelationship to other fixes
Combined, the chain-side fixes (binpatch fd-close + getsentry/cli CI workflow) and this action-side fix mean the consumer can stop running its own hand-rolled patch generation/publish and consume the binpatch action directly.
Verification