ElixirForge/DFTE
1
0
Fork 0
mirror of https://github.com/alexhopeoconnor/DFTE.git synced 2026-10-04 04:28:10 +10:00
Code Releases Activity

ci: add current ESP32 validation lane

Browse Source
This commit is contained in:
alex
2026-09-17 12:10:53 +10:00
parent 42cb8f2324
commit ec4c32db32
11 changed files with 113 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/DEVELOPMENT.md
+33 -9
View File
@@ -4,16 +4,37 @@ Released applications should use a public Git tag. While changing DFTE with a si
## Target pins
The ESP32 test and example environments pin pioarduino `51.03.05`, which
selects Arduino-ESP32 3.0.5 / ESP-IDF 5.1.4+. This is a fixture contract, not a
DFTE package dependency: a consuming application owns its `platform` pin and
tests the complete framework/toolchain stack. The ESP8266 environments pin
framework commit `521ae60` for the upstream Postmortem large-jump linker fix;
the exact rationale and update rule are in the shared [ESP8266
linker-workaround note](https://github.com/alexhopeoconnor/arduino-home-assistant/blob/main/docs/ESP8266-LINKER-WORKAROUND.md).
DFTE keeps two explicit ESP32 fixture lanes while consumers move to the current
framework baseline:
For the pioarduino release-to-Core mapping and the narrow repair for a stale
global PlatformIO tool package, see [DeviceFramework's toolchain guide](https://github.com/alexhopeoconnor/DeviceFramework/blob/main/docs/TOOLCHAINS.md).
| Test selector | pioarduino platform | Framework stack | Purpose |
| --- | --- | --- | --- |
| `esp32` | `51.03.05` | Arduino-ESP32 3.0.5 / ESP-IDF 5.1.4+ | Deliberate legacy compatibility coverage |
| `esp32_3_3_11` | `55.03.311` | Arduino-ESP32 3.3.11 / ESP-IDF 5.5.5 | Current validation baseline |
These are fixture contracts, not DFTE package dependencies: a consuming
application owns its `platform` pin and tests the complete framework/toolchain
stack. Do not copy a compiler or toolchain package between lanes; each pinned
pioarduino platform resolves its matched framework, uploader, and toolchain.
The legacy lane is retained deliberately until the supported ESP32 floor is
changed in a reviewed compatibility decision.
All DFTE ESP8266 test and example environments pin framework commit `521ae60`
for the upstream Postmortem large-jump linker fix. The exact rationale and
update rule are in the shared [ESP8266 linker-workaround
note](https://github.com/alexhopeoconnor/arduino-home-assistant/blob/main/docs/ESP8266-LINKER-WORKAROUND.md).
For the pioarduino release-to-Core mapping and cache-collision diagnosis, see
[DeviceFramework's toolchain guide](https://github.com/alexhopeoconnor/DeviceFramework/blob/main/docs/TOOLCHAINS.md).
`./scripts/test.sh` keeps the `esp32_3_3_11` lane in a dedicated PlatformIO
Core/cache directory by default:
`${XDG_CACHE_HOME:-$HOME/.cache}/dfte-platformio/core-3.3.11`. That prevents a
legacy 3.0.5 `tool-esptoolpy` installation from shadowing the current
pioarduino uploader. Override it with `DFTE_PLATFORMIO_CORE_DIR`,
`DFTE_PLATFORMIO_PACKAGES_DIR`, and `DFTE_PLATFORMIO_CACHE_DIR` for another
disk or a disposable clean-room investigation; do not delete an unrelated
global toolchain or pin one compiler separately.
Start a release with `bump-version.sh`. It updates package metadata and canonical installation snippets, then creates the changelog section. Replace its generated TODO with the release summary and update any behavioural documentation before running:
@@ -25,6 +46,9 @@ Start a release with `bump-version.sh`. It updates package metadata and canonica
./scripts/test.sh compile --platform esp32
./scripts/test.sh examples --platform esp8266
./scripts/test.sh examples --platform esp32
./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
./scripts/prepare-release.sh vMAJOR.MINOR.PATCH --tag
```
docs/TESTING.md
+16 -2
View File
@@ -1,15 +1,29 @@
# Testing
The two PlatformIO Unity commands compile the complete DFTE test suites without uploading or executing them, so they require no attached board.
The three PlatformIO Unity commands compile the complete DFTE test suites without uploading or executing them, so they require no attached board.
```bash
./scripts/test.sh compile --platform esp8266
./scripts/test.sh compile --platform esp32
./scripts/test.sh examples --platform esp8266
./scripts/test.sh examples --platform esp32
./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 first two commands compile the library test suites with `test_build_src = yes`. The example commands compile every standalone project on each target, protecting the code that the documentation links users to. CI runs the library target checks on the maintained branch and pull requests.
`esp32` is the explicit Arduino-ESP32 3.0.5 compatibility lane.
`esp32_3_3_11` uses pioarduino `55.03.311` (Arduino-ESP32 3.3.11 / ESP-IDF
5.5.5) as the current validation baseline. The three `compile` commands
compile the complete suites with `test_build_src = yes`; the example commands
compile every standalone project on each target, protecting the code that the
documentation links users to. CI runs every listed target lane on the
maintained branch and pull requests.
The current lane is isolated by the script in a dedicated Core/cache directory
so the package-form Arduino-ESP32 Core 3.3.11 uploader cannot inherit legacy 3.0.5 Python
metadata. `packages` prints the resolved package graph after the current build;
it is a verification step, not a request to change a compiler pin.
The standalone examples are buildable PlatformIO projects; see [examples](../examples/README.md).