ci: upload bin artifacts for RISC-V esp32 chips in user build - #903
Conversation
RISC-V esp32 chips (c3/c6/h2) build in the generic job but espflash produces .bin images, which only build_esp (esp32s3) uploaded. Add a bin upload step and gate uf2/hex uploads to non-esp32 chips.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Size Report
|
|
Worked for me just now using peterjc/rmk-pico-keyboards@ed79a25 after I did a full re-run of the GitHub Actions - thank you!
|

Problem
RISC-V esp32 chips (esp32c3/c6/h2) don't match the
build_espgate (chip_name == 'esp32s3'), so they run in the genericbuildjob. The build succeeds — cargo-make auto-installscargo-espflash, and the template'suf2task produces.binimages — but the job only uploadsrmk/*.uf2andrmk/*.hex, so no artifacts appear.Reported by @peterjc for an esp32h2 split build: https://github.com/peterjc/rmk-pico-keyboards/actions/runs/28672157097/job/85037673964
Fix
Upload bin artifactsstep (rmk/*.bin) to the genericbuildjob, gated to esp32 chips.build_espstays gated on exactlyesp32s3— it exists for the Xtensa/espup toolchain, which RISC-V esp32 chips don't need.Companion fix in rmk-template names the split esp32 images
<project>-central.bin/<project>-peripheral.bininstead of hardcodedcentral.bin/peripheral.bin: rmk-rs/rmk-template#24Verification
actionlint: no new findings vs.main(11 pre-existing info-level shellcheck notes on both).cargo make uf2 --release: producedFly_Half_ESP32H2-central.binandFly_Half_ESP32H2-peripheral.bin, which the newrmk/*.binglob matches.