Repository navigation
ci(companion): build one firmware per runner with cached toolchains - #9
Merged
Merged
Conversation
The companion release built all boards one after another on a single runner, re-downloading the PlatformIO toolchains every time. Split it like the DMC observer workflow: - prepare: resolve the version and release tag once, and read the board list from the new `build.sh get-meshcomod-companion-firmwares-to-build` (MESHCOMOD_COMPANION_ENVS stays the single list). - build: a matrix with one runner per board, fail-fast off, caching ~/.platformio packages and platforms per platformio.ini and each board's libdeps per ini files (plus the in-repo AsyncElegantOTA copy). - release: collect all boards, upload the combined companion-firmwares artifact as before, then create the (pre-)release and prune. The release only runs when every board built, so a failed board blocks the release instead of it shipping without that board. Tag handling, pre-release numbering and retention are unchanged.
The four usb_tcp envs from #7 were defined but not in MESHCOMOD_COMPANION_ENVS, so the companion release never built them. Add them; with the matrix workflow each gets its own runner, and the OTA server picks them up by their _companion_radio_usb_tcp suffix. Board lists follow: README supported devices, the CI releases table and the build.sh help text. The README touch note now says touch UI builds, since a non-touch V4 TFT build is released from here. The new boards build but have not been tested on hardware.
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.
What changed
Two commits.
1.
ci(companion): one runner per firmware, with caches (.github/workflows/build-companion-firmwares.yml,build.sh)The workflow is split into three jobs, following the DMC observer workflow:
prepare: resolves the version, release tag and pre-release flag once (same rules as before), and gets the board list from the newbuild.sh get-meshcomod-companion-firmwares-to-build, which printsMESHCOMOD_COMPANION_ENVS. That array stays the only board list.build: a matrix with one runner per board,fail-fast: false. Caches:~/.platformio/packagesand~/.platformio/platforms, keyed onplatformio.ini(with a restore-key fallback). The espressif32 toolchain and framework are pinned there, so this skips the large download and unpack on every runner..pio/libdeps/<env>, keyed on the board, all ini files, andarch/esp32/AsyncElegantOTA/**(the in-repofile://library, so its copy cannot go stale). Exact key only: anylib_depschange installs fresh.build.shputs the version and build date in the global flags, which invalidates them anyway.~/.platformio/.cachecache insetup-build-environmentis untouched.release: downloads everyfw-<env>artifact intoout/, uploads the combinedcompanion-firmwaresartifact as before, then creates the release and prunes, both only when there is a tag (unchanged).One deliberate behaviour change: the release job needs every board to build. With fail-fast off, the other boards still finish and the failure shows in the run, but no release is published without a board. Before, a failure stopped the single sequential job.
2.
feat(companion): release the four new usb_tcp boards (build.sh,README.md,docs/CI_RELEASES.md)Adds
heltec_v4_r8_companion_radio_usb_tcp,heltec_v4_r8_tft_companion_radio_usb_tcp,heltec_v4_tft_companion_radio_usb_tcpandHeltec_WSL3_companion_radio_usb_tcp(from #7) toMESHCOMOD_COMPANION_ENVS, and updates the README supported devices table, the CI releases table and thebuild.shhelp text. The README touch note now says "touch UI builds", because a non-touch V4 TFT build ships from here.A companion release now builds 10 boards: V4, V3, Wireless Paper, Xiao, V4 R8, V4 R8 TFT, V4 TFT and WSL3 (all
_usb_tcp), plus ThinkNode M7 BLE and Ethernet.Why
The release built everything one board after another on a single runner and downloaded the toolchains every time. With 10 boards that gets slow. The four new boards were defined in #7 but were never built by the release.
How it was tested
bash build.sh get-meshcomod-companion-firmwares-to-buildprints the 10 envs. Each one resolves to an[env:...]section invariants/, and the jq conversion gives the matrix JSON.actionlinton the workflow: no findings in the workflow itself. It reports that.github/actions/setup-build-environment/action.ymlhas nodescription, which predates this PR.build.sh build-firmwarein feat(companion): add usb_tcp envs for V4 R8, V4 R8 TFT, V4 TFT and WSL3 #7 (sizes are in that PR).prerelease), which builds everything and uploads artifacts without publishing.Firmware and build impact
No firmware source changes. Release assets gain the four new boards (
<env>.bin,-merged.bin,.partsig, plus the timestamped copiesmerge-bin.pywrites). The web flasher still needs entries for them; the OTA server picks them up by suffix. The new boards are not tested on hardware.No issue to close.