ci: add current ESP32 validation lane

This commit is contained in:
2026-09-17 12:10:59 +10:00
parent e3c9388ffc
commit ea6f1cf353
11 changed files with 120 additions and 9 deletions
+8 -2
View File
@@ -1,7 +1,7 @@
# ESP8266 Postmortem linker workaround
The ESP8266 Arduino framework pin used by the DeviceFramework, WiFiManager,
and DFTE test projects is intentional:
DFTE, and ArduinoHA maintained builds is intentional:
```ini
platform_packages =
@@ -14,11 +14,17 @@ It changes the restart wrapper to use a relaxed jump and adds an EPC1 address
check. The failure is a framework linker/runtime-support issue, not an ArduinoHA
or application-source error.
ArduinoHA's root `pio test -e esp8266` environment and every guided ESP8266
PlatformIO example now use this same snapshot. There is no root-test exception
that can hide a linker regression from the example contract.
Keep this exact framework snapshot in ESP8266 environments that need the
maintained test contract. It is unrelated to ESP32, whose pioarduino platform
selects its framework and compiler as a unit. Do not replace the SHA with a
version range: remove or advance the pin only after an upstream release includes
the fix and the affected large firmware has compiled successfully.
the fix and the affected large firmware has compiled successfully. In
particular, changing the ESP32 validation lane does not justify changing this
ESP8266 pin.
The corresponding ESP32 Core 3 pin and shared PlatformIO-cache recovery steps
are documented in [DeviceFramework's toolchain guide](https://github.com/alexhopeoconnor/DeviceFramework/blob/main/docs/TOOLCHAINS.md).
+41 -1
View File
@@ -16,6 +16,45 @@ The only imported upstream code fix is the four missing-device-ID guards from
upstream commit `9c9d074`. Device discovery migration, JSON validation,
lifecycle handling, and tests are fork-native changes.
## Arduino framework validation lanes
ArduinoHA compiles its embedded test suites and guided PlatformIO examples in
three deliberately named lanes:
| Selector | Target | Pinned stack | Role |
| --- | --- | --- | --- |
| `esp8266` | ESP8266 D1 mini | Arduino-ESP8266 commit `521ae60` | Maintained Postmortem linker-fix contract |
| `esp32` | ESP32 Dev Module | pioarduino `51.03.05` / Arduino-ESP32 3.0.5 | Legacy compatibility coverage |
| `esp32_3_3_11` | ESP32 Dev Module | pioarduino `55.03.311` / Arduino-ESP32 3.3.11 / ESP-IDF 5.5.5 | Current validation baseline |
The ESP32 3.0.5 lane remains intentional compatibility coverage until the
supported floor is changed in a reviewed release decision. It is not allowed to
select a framework or compiler from a global PlatformIO cache by accident;
every lane pins its complete pioarduino platform. The ESP8266 framework pin is
independent of both ESP32 lanes; see the [linker workaround](ESP8266-LINKER-WORKAROUND.md).
Run the current ESP32 lane locally with:
```bash
./scripts/test.sh compile --platform esp32_3_3_11
./scripts/test.sh packages --platform esp32_3_3_11
./scripts/test.sh examples --platform esp32_3_3_11
```
The script keeps that current lane in a dedicated PlatformIO Core/cache
directory by default (`${XDG_CACHE_HOME:-$HOME/.cache}/arduinoha-platformio/core-3.3.11`).
This prevents a legacy 3.0.5 `tool-esptoolpy` cache from shadowing the current
pioarduino package-form uploader. Set `ARDUINOHA_PLATFORMIO_CORE_DIR`,
`ARDUINOHA_PLATFORMIO_PACKAGES_DIR`, and
`ARDUINOHA_PLATFORMIO_CACHE_DIR` for a dedicated disk or a disposable
clean-room check; do not repair this condition by overriding a single compiler
or deleting an unrelated global toolchain.
The embedded multi-suite compile path also defaults
`PLATFORMIO_RUN_JOBS=1`. A caller may explicitly set another value, but the
serial default avoids a reproducible PlatformIO archive missing-object race
seen in the Core 3.3.11 lane. Example builds remain parallel.
## Deliberate exclusions
- No merge or wholesale cherry-pick of upstream `develop` / WIP 2.2.0.
@@ -37,4 +76,5 @@ git diff --stat main...upstream/develop
Port only independently reviewed changes with regression tests; treat open
upstream pull requests as proposals, not release inputs. Run the native,
board-compile, and HA test harness gates before publishing a new release.
board-compile (including both ESP32 lanes), and HA test harness gates before
publishing a new release.