The esp32-stm32-vcu firmware build generates common-yaml headers with python3 generate.py, which needs pyyaml + jinja2. After the runner migrated firmware jobs into the localhost/gitea-ci-espidf container, that step failed:
the base image's system Python is PEP 668 externally-managed → pip install pyyaml jinja2 fails;
the IDF venv (which has pyyaml) isn't on PATH in the runner's docker-exec step shell.
Change
Install python3-yaml + python3-jinja2 as distro packages in Containerfile.espidf.j2, so firmware jobs run a plain python3 generate.py — no pip at job time, no IDF sourcing just to generate headers.
Deploy + verification
Already deployed: make deploy TAGS=gitea-actions rebuilt localhost/gitea-ci-espidf:v5.4.1 on home.debyl.io.
Verified the rebuilt image's system Python (the context the runner execs in): python3 -c "import yaml, jinja2" → yaml 6.0.1 jinja2 3.1.2.
esp32-stm32-vcu PR #33 CI is now green end-to-end (header-gen → idf.py build → S3 artifact) with a simplified workflow.
## Why
The `esp32-stm32-vcu` firmware build generates common-yaml headers with `python3 generate.py`, which needs **pyyaml + jinja2**. After the runner migrated firmware jobs into the `localhost/gitea-ci-espidf` container, that step failed:
- the base image's system Python is **PEP 668** externally-managed → `pip install pyyaml jinja2` fails;
- the IDF venv (which has pyyaml) isn't on PATH in the runner's docker-exec step shell.
## Change
Install `python3-yaml` + `python3-jinja2` as distro packages in `Containerfile.espidf.j2`, so firmware jobs run a plain `python3 generate.py` — no pip at job time, no IDF sourcing just to generate headers.
## Deploy + verification
- Already deployed: `make deploy TAGS=gitea-actions` rebuilt `localhost/gitea-ci-espidf:v5.4.1` on `home.debyl.io`.
- Verified the rebuilt image's system Python (the context the runner execs in): `python3 -c "import yaml, jinja2"` → `yaml 6.0.1 jinja2 3.1.2`.
- esp32-stm32-vcu PR #33 CI is now **green** end-to-end (header-gen → `idf.py build` → S3 artifact) with a simplified workflow.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The esp32-stm32-vcu firmware build generates common-yaml headers with
`python3 generate.py`, which needs pyyaml + jinja2. The runner's base Python is
PEP 668 externally-managed (pip install fails) and the IDF venv isn't on PATH in
the docker-exec step shell, so install both as distro packages. Lets firmware
jobs run a plain `python3 generate.py` with no pip and no IDF sourcing.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bastian
merged commit 511db704a4 into master2026-06-19 16:06:03 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
The
esp32-stm32-vcufirmware build generates common-yaml headers withpython3 generate.py, which needs pyyaml + jinja2. After the runner migrated firmware jobs into thelocalhost/gitea-ci-espidfcontainer, that step failed:pip install pyyaml jinja2fails;Change
Install
python3-yaml+python3-jinja2as distro packages inContainerfile.espidf.j2, so firmware jobs run a plainpython3 generate.py— no pip at job time, no IDF sourcing just to generate headers.Deploy + verification
make deploy TAGS=gitea-actionsrebuiltlocalhost/gitea-ci-espidf:v5.4.1onhome.debyl.io.python3 -c "import yaml, jinja2"→yaml 6.0.1 jinja2 3.1.2.idf.py build→ S3 artifact) with a simplified workflow.🤖 Generated with Claude Code