bastian/deploy_home
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

gitea-actions: add python3-yaml + python3-jinja2 to the ESP-IDF CI image #6

Merged
bastian merged 1 commits from gitea-ci-espidf-python-deps into master 2026-06-19 16:06:03 -04:00
Conversation 0 Commits 1 Files Changed 1
+8 -3
bastian commented 2026-06-19 16:03:58 -04:00
Owner
Copy Link
Copy Source

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

## 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)
bastian added 1 commit 2026-06-19 16:03:59 -04:00
gitea-actions: add python3-yaml + python3-jinja2 to the ESP-IDF CI image 285ef2ad01 
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 master 2026-06-19 16:06:03 -04:00
bastian deleted branch gitea-ci-espidf-python-deps 2026-06-19 16:06:03 -04:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
bastian (Bastian)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bastian/deploy_home#6
Delete Branch "gitea-ci-espidf-python-deps"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?