Repository navigation
ci(firmware): build and attach firmware release assets (#360) - #368
Merged
Merged
Conversation
… Gateway The Gateway PCB carries an STM32F103C8, and the variant policy and docs already name the C8 for PanelBridge; only the template still targeted the CB. PanelBridge links at 31,348 B (47.8% of the C8). The library README named the CBT6 too. Refs #360
A reusable workflow builds the stock firmware - the Gateway (SimGateway .uf2 + PanelBridge) and the three PDU nodes - from the release tag and attaches it to the firmware release: one .bin/.uf2 per board plus manifest.json (size, SHA-256) for tools, and a zip with a folder per board, .elf files and READMEs (from Firmware/release templates) for people. release-please.yml calls it with publish: true once a firmware release exists. Pull requests touching the workflow or the templates, and manual runs, only validate: they build, put a flash/RAM table per board in the job summary and upload the package as an Actions artifact. Closes #360
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
… typed one CodeQL flagged the workflow_dispatch ref input: a manual run checked out whatever ref was typed in. Drop the input; a manual run now builds the branch or tag picked in "Use workflow from", and only the release call (tag from release-please) passes a ref. Refs #360
…separate caller CodeQL's cache-poisoning check still flagged the checkout: in a workflow that also has a workflow_dispatch trigger, any inputs.ref checkout counts as dispatch-controlled. The build workflow now has only workflow_call; pull-request and manual validation runs live in firmware-release-assets-check.yml, which calls it without a ref. The ref it checks out only ever comes from release-please. Refs #360
…d-in ref CodeQL kept flagging the inputs.ref checkout as dispatch-controlled. The release path doesn't need it: the release job runs on the push that merged the release PR, which is the commit release-please tags. The input is now 'tag' and only names the files and the release; the build fails if the tag doesn't point at the commit it built. The validation workflow drops its manual trigger: pull requests already cover iterating on the package. Refs #360
6 tasks done
This was referenced Oct 25, 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
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 #360.
What
Every firmware release gets prebuilt firmware attached, built by CI from the release tag.
.github/workflows/firmware-release-assets.yml(workflow_callonly)publish: truebyrelease-please.yml(newfirmware-assetsjob, besidefirmware-dependencies) — the only path that publishes (gh release upload --clobber)..github/workflows/firmware-release-assets-check.ymlon pull requests (the two workflows +Firmware/release/**) — validation only: build, flash/RAM table per board in the job summary, package uploaded as an Actions artifact (14 days). No manual trigger.Templates/SimGateway(.uf2) +Templates/PanelBridge;Panels/PDU_Left|Right|Center.Center_Armamentleft out (deprecated board).manifest.json,gateway-<v>.uf2,gateway-bridge-<v>.bin,pdu-left|right|center-<v>.bin.openskyhawk-firmware-<v>/— top README / CHANGES / LICENSE / manifest, then a folder per board with its README and.elf(STM32, flash address built in) or.uf2(RP2040).Firmware/release/(top, Gateway, STM32 node), filled withenvsubst. GPL note points at the release's source archive.genericSTM32F103C8, the MCU on the Gateway board (the docs already said C8). Links at 31,348 B (47.8%).docs/architecture/design-decisions.md: one bullet on what a firmware release carries.Checked locally (before this PR)
All five projects build from this branch; the workflow's packaging script, extracted from the YAML and run against those builds, produced the expected flat files, zip tree and READMEs, and every manifest SHA-256 matches its file (
sha256sum -c).Not covered here
BEGIN_COMMIT_OVERRIDE
ci(firmware): build and attach firmware release assets (#360)
fix(firmware): PanelBridge template builds for the STM32F103C8 on the Gateway (#360)
END_COMMIT_OVERRIDE