Repository navigation
Bump ESP-IDF to v5.5.6 - #57
Merged
Merged
Conversation
Replaces v5.5.5 in place: the esp-idf primary variant and both Matter variants built on it (v1.6, v1.5.1) move to v5.5.6 with their esp-matter pins unchanged. The published v5.5.5 tags stay in GHCR; they are simply no longer rebuilt.
There was a problem hiding this comment.
🟢 Approved
Remaining feedback is limited to non-blocking documentation nits.
1 open issue
What changed in this PR
Updates ESP-IDF from v5.5.5 to v5.5.6 across ESP-IDF and ESP-Matter variants.
Changes:
- Updates version metadata and published tags.
- Updates Dockerfile defaults and version assertions.
- Preserves existing Matter pins and older variants.
| File | Description |
|---|---|
images/versions.json |
Updates ESP-IDF and ESP-Matter version metadata. |
images/esp-matter/Dockerfile |
Uses the v5.5.6 ESP-IDF base and matching version. |
images/esp-idf/Dockerfile |
Uses ESP-IDF v5.5.6 as the base. |
Review effort: Lite
hacker-cb
added a commit
that referenced
this pull request
Oct 17, 2026
Образы ESP-IDF v5.5.6 из [#57](#57) ломают сборку под задокументированным `-u $(id -u):$(id -g)`: CMake configure любого проекта падает с `PermissionError: '/opt/esp/root_managed_components'`. Нашёл потребитель — батч [jethome-iot/jetcontrol-cpp#2005](jethome-iot/jetcontrol-cpp#2005): так у него ломалась каждая ESP32-сборка. Сборка от root, в том числе собственный слой проверки образа, продолжала проходить. ## Почему так В ESP-IDF 5.5.6 появился `tools/idf_extra_components.yml` (все строки закомментированы). Как только этот файл есть, менеджер компонентов (`prepare_dep_dirs`) при каждом configure пишет `$IDF_TOOLS_PATH/root_managed_components/idf5.5/dependencies.lock` и сначала создаёт этот каталог. `/opt/esp` принадлежит root. В 5.5.5 файла не было. Обойти это переменной окружения нельзя. Каталог выводится только из `IDF_TOOLS_PATH` (`idf_component_tools.config.config_dir()`, запасной вариант — `~/.espressif`), а по `IDF_TOOLS_PATH` образ находит тулчейны. Готовый lock, созданный при сборке от root, тоже не подходит: в нём записан `target`, и при каждой смене цели файл переписывается на месте (`open(path, 'w')`). Проверено: под чужим uid отказ случается на первом же `set-target`. ## Что изменилось - **`images/esp-idf/Dockerfile`**: - новый слой — `install -d -m 1777 "${IDF_TOOLS_PATH:?}/root_managed_components"`. Создаётся пустым и только верхний уровень: подкаталог `idf<major.minor>` заводит первый uid, выполнивший configure, и дальше он принадлежит этому uid. Один uid на контейнер — то, что даёт `docker run -u`, — проходит на любой цели. Второй uid в том же контейнере падает при смене цели. Комментарий и README об этом говорят прямо; - **слой проверки** настраивает `hello_world` под uid 54321, у которого нет записи в passwd, через entrypoint образа: сначала цель по умолчанию, затем `set-target esp32c3`. Если в SDK есть `idf_extra_components.yml`, слой требует, чтобы lock появился и принадлежал этому uid; в 5.4.1 этого файла нет. `HOME` и `TMPDIR` направлены во временный каталог проверки. Затем слой удаляет из `root_managed_components` всё, что записал этот uid, и проверяет режим 1777 и что в `/tmp` и `/var/tmp` от этого uid ничего не осталось. Если `setpriv` нет или он не может сбросить привилегии, слой так и сообщает, как это уже делает esp-matter. - **`images/esp-matter/Dockerfile`** — тот же `install -d` (идемпотентный) для баз, собранных до этого слоя: на них, в том числе на уже опубликованном `idf-v5.5.6`, локальная сборка esp-matter иначе снова сломалась бы под `-u`. Слой проверки требует, чтобы каталог оставался пустым и с режимом 1777 после `install.sh`, который выполняется от root. - **`images/esp-idf/README.md`** — раздел *Building as Your Own User*: пример с `-u` и `-e HOME=/tmp`, что образ подготовил для этого случая и чего не покрывает. Записываемый `HOME` по-прежнему за вызывающим: без него configure падает на кэше менеджера компонентов (`~/.cache/Espressif/ComponentManager`). Так было и на 5.5.5. - **`images/esp-matter/README.md`** — абзац о `-u` ссылается на этот раздел. Файл SDK `idf_extra_components.yml` не меняется — так просил потребитель. ## Как проверено Локально, `./scripts/build.sh esp-idf` (linux/arm64, `IDF_BASE_TAG=v5.5.6`): | проверка | результат | |---|---| | сборка образа | зелёная; `configure as uid 54321, esp32 then esp32c3: ok` | | тот же Dockerfile без слоя 1777 | слой проверки падает: `PermissionError`, `configure as uid 54321 failed` | | `root_managed_components` в образе | `1777 root`, пустой; в `/tmp` от uid 54321 ничего нет (до исправления оставался `/tmp/esp_idf_activate` этого uid) | | пример из README под `-u $(id -u):$(id -g) -e HOME=/tmp` | `hello_world` собирается для esp32, затем `set-target esp32c6` и снова собирается; `build/` принадлежит вызывающему | | образ v5.5.6 без исправления (локальная сборка master) под `-u` | воспроизводит `PermissionError`; на опубликованном `idf-v5.5.6-r39022168715.1` его воспроизвёл потребитель | | `check-versions.sh`, `check-pins.sh`, `lint.sh` | зелёные (у hadolint только прежние предупреждения) | esp-matter и вариант `idf-v5.4.1` локально не собирались: для esp-matter нужно около 50 ГБ диска, а свободно меньше. Их проверяют сборки CI на этом PR, где esp-matter собирается поверх esp-idf этого же запуска. Локальное ревью — раунд уровня high. У Claude полное покрытие, у Codex частичное: ему не хватило сети, чтобы прочитать Dockerfile базовых образов. Девять находок `Minor`. Шесть исправлены в `30d0476`: различение отсутствующего `setpriv`, путь через entrypoint, смена цели, требование lock-файла, `${IDF_TOOLS_PATH:?}`, кавычки вокруг `$(pwd)`. Три отклонены: - убрать или обезвредить `idf_extra_components.yml` — потребитель просил файл SDK не трогать, а с первым же раскомментированным пакетом upstream это решение сломалось бы; - не создавать каталог в esp-matter — сделано намеренно, ради баз без этого слоя; - вынести кэш менеджера компонентов из `HOME` — требование существовало и до 5.5.6, это отдельное решение об окружении образа. Исправление с `TMPDIR` и проверку остатков в `/tmp` после этого ещё раз прочитал Codex: полное покрытие, находок нет. После слияния воркфлоу ESP-IDF опубликует новые `idf-v5.5.6-r<run>.<attempt>` и `idf-v5.5.6-matter-v1.6-r<run>.<attempt>` — их передадут в [jethome-iot/jetcontrol-cpp#2005](jethome-iot/jetcontrol-cpp#2005).
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.
ESP-IDF поднят с v5.5.5 до v5.5.6 (выпуск 2026-10-16; в подмодуле mbedTLS 3.6.7). Заказ пришёл от потребителя: jethome-iot/jetcontrol-cpp#2005 снимает уязвимости mbedTLS 3.6.6 и переезжает на образы v5.5.6 одним коммитом. Образ host не меняется.
Что изменилось
images/versions.json— версия заменена на месте, не добавлена рядом:idf-v5.5.5→idf-v5.5.6,IDF_BASE_TAG=v5.5.6;idf-v5.5.6-matter-v1.6(основной) иidf-v5.5.6-matter-v1.5.1,base_tagиIDF_VERSIONвслед за базой. Закреплённые коммиты esp-matter не меняются:release/v1.6—2c125619, на нём же стоит потребитель;release/v1.5—44dfffd0.images/esp-idf/Dockerfile,images/esp-matter/Dockerfile— значенияARGпо умолчанию (IDF_BASE_TAG,BASE_IMAGE,IDF_VERSION) приведены к новым данным: их сверяетcheck-versions.sh, и по ним собирает локальныйbuild.sh.images/esp-matter/README.md(пример написанияIDF_VERSION) больше не называют конкретный выпуск: вместоv5.5.5—v<version>/v<idf-version>, иначе каждое поднятие версии оставляло бы их устаревшими. Упоминанияidf-v5.5.5вCLAUDE.mdиscripts/check-versions.shоставлены: они разбирают, почемуv5.5не должен проходить под тегомidf-v5.5.5, и цифры там нужны для примера.Почему версия заменяется на месте: потребитель закрепляет тег одной сборки (
-r<run-id>.<attempt>). Опубликованные теги v5.5.5, включая закреплённый у негоidf-v5.5.5-r34257882007.1, остаются в GHCR как есть — просто больше не пересобираются. Веткаidf-v5.4.1и Matter v1.4.2 на ней не трогаются.Учтите: README esp-matter на обоих закреплённых коммитах (и на голове
release/v1.6,80b0936) рекомендует ESP-IDF v5.5.5. v5.5.6 — патч-релиз той же ветки 5.5, и сочетание проверяет сборка esp-matter на этом PR: она идёт под обе архитектуры на esp-idf v5.5.6, собранном тем же запуском. Потребитель предупреждён и проверит Matter-сборку у себя.Как проверено
espressif/idf:v5.5.6в Docker Hublinux/amd64иlinux/arm64check-versions.sh,check-pins.sh./scripts/build.sh esp-idf(linux/arm64)ESP-IDF v5.5.6совпал с меткой,esptool==5.3.1,pip checkпроходитdev.jethome.idf.version=v5.5.6,org.opencontainers.image.version=idf-v5.5.6,base.name=espressif/idf:v5.5.6hello_worldиз$IDF_PATH/examplesдля esp32 в образе;idf.py --list-targets;qemu-system-xtensa --versionЛокальное ревью — раунд уровня high: у Claude полное покрытие, находок нет. Codex прошёл частично: ему не хватило сети для данных из upstream (тег Docker Hub, README esp-matter); эти данные сверены вручную, они перечислены выше.
После слияния воркфлоу ESP-IDF опубликует
idf-v5.5.6-r<run>.<attempt>иidf-v5.5.6-matter-v1.6-r<run>.<attempt>— их передадут в jethome-iot/jetcontrol-cpp#2005.