fix: Use image from wheels for ARMv7 builds#10
Conversation
👋 Hello peterdragun, we appreciate your contribution to this project! 📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more. Click to see more instructions ...
Review and merge process you can expect ...
|
There was a problem hiding this comment.
Pull request overview
This PR updates the composite GitHub Action’s ARMv7 build path to run inside the same container image used to build/publish the ARMv7 wheels, aiming to avoid uv selecting incompatible wheels (e.g., OpenSSL mismatch) and to reduce per-run dependency setup.
Changes:
- Switch ARMv7 builds from
uraimo/run-on-arch-action@v3to a directdocker runonghcr.io/espressif/.../idf-python-wheels-armv7l:v1. - Add QEMU setup (
docker/setup-qemu-action@v3) for ARMv7 Docker execution. - Update documentation and input descriptions to reflect that the ARMv7 image already contains most build dependencies.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| action.yml | Reworks ARMv7 build execution to run inside the wheels image, adds QEMU setup, and updates ARM package input docs. |
| README.md | Updates ARMv7 usage examples and input table to match the new ARMv7 image assumptions. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
92ad2ae to
4c8fb52
Compare
jakub-kocka
left a comment
There was a problem hiding this comment.
Thank you, @peterdragun, for this fix! LGTM.
I am also mentioning related PR here, which introduces an updated approach to building the cPython packages and esptool dependencies: espressif/idf-python-wheels#63
4c8fb52 to
ea45871
Compare
Description
We had an issue with building esptool on armv7. The main issue was
uvdownloading the incorrect wheel from our index, and that failed on the wrong version of OpenSSL, see: https://github.com/espressif/esptool/actions/runs/22508432922/job/65212183798This is a workaround for this issue. If we are going to use the same image that was used to generate the wheel, this should be more stable. Also, this should improve the performance since we don't need to install packages on every run (to be fair, there was a cache anyway, but having it in one place in docker image is nicer)
Related
Testing