release.yml: Support backfilling assets via workflow_dispatch - #18
Merged
Merged
Conversation
A manual workflow_dispatch re-run (added in a567c26 to backfill v1.0.0's missing bootloader/partitions/boot_app0 assets) must target the vX.Y.Z tag via the ref dropdown. Left on the default branch, GITHUB_REF_NAME is a branch name like "main" and the existing check failed with a misleading "bump version.h to match" message — that's exactly what happened re-running against v1.0.0 (dispatched against main by mistake). Now it calls out the wrong-ref mistake directly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LJFxsP371u76Ci5y2Wpf7U
GitHub only allows workflow_dispatch against a ref whose own copy of the workflow file already defines the trigger — a tag cut before this trigger existed (v1.0.0) can never be dispatched against directly. Confirmed today trying exactly that: "Workflow does not have 'workflow_dispatch' trigger". The previous design assumed picking the tag from the ref dropdown would work; it doesn't and never could. Now workflow_dispatch takes an explicit `tag` input naming the release to attach built assets to, and always runs from a branch (main). Safe because "Verify version.h" still checks the checked-out source actually matches that tag's version before building or uploading anything — src/ is unchanged since v1.0.0 was cut, so building from main's tip produces the same firmware. Also scopes generate_release_notes off for the dispatch path: the action would otherwise regenerate v1.0.0's release notes from this run's own commit, silently pulling in every commit landed since instead of just backfilling the missing bootloader/partitions/boot_app0 assets. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LJFxsP371u76Ci5y2Wpf7U
The stored file is the fixed name firmware.bin (copy_track() keeps it generic so manifest.json's part paths don't change between versions), and the <a download> links had no filename hint, so the browser was suggesting "firmware.bin" for every download regardless of which build it came from. Sets an explicit download="LoRaTraceRX-<version>.bin" per track instead of renaming the stored file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LJFxsP371u76Ci5y2Wpf7U
d3mocide
had a problem deploying
to
github-pages
September 3, 2026 23:58 — with 
GitHub Actions
Failure
GitHub Actions
Failure
This branch had an error being deployed
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
2 participants
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
Extend the release workflow to support manual re-runs against existing release tags, enabling asset backfill when workflow changes add new build artifacts after a release ships. Previously, releases could only be triggered by pushing a new tag; now they can be manually dispatched against any existing tag via the Actions UI.
Key Changes
workflow_dispatchinput: Newtaginput parameter allows specifying an existing release tag (e.g.,v1.0.0) when manually triggering the workflowGITHUB_REF_NAMEGITHUB_REF_NAMEworkflow_dispatch${GITHUB_REF_NAME}to${{ steps.tag.outputs.value }}for consistency with the resolved tagtag_nameto the resolved tag (required forworkflow_dispatchto target the correct release)generate_release_notesforworkflow_dispatchruns to prevent overwriting existing release notes with the dispatch branch's commit historydraft: falseonly for tag-push triggers; dispatch runs attach to existing releases as-isImplementation Details
The workflow now supports two trigger paths:
The version.h verification step serves dual purposes: it ensures release correctness for tag-push triggers AND prevents accidental asset mismatches when dispatching against the wrong tag or branch. This is critical because
workflow_dispatchchecks out the dispatch branch (typicallymain), not the tagged commit itself.Release notes are only auto-generated for tag-push triggers; dispatch runs preserve the original release notes and only add missing asset files.
https://claude.ai/code/session_01LJFxsP371u76Ci5y2Wpf7U