Remove inappropriate usermod environment changes#5720
Conversation
Catch any incorrect debug prints for all targets.
WalkthroughUsermod build flags were updated in PlatformIO config and usermod override files, and the usermods GitHub Actions workflow now builds a per-usermod, per-environment matrix from override samples or the shared override. ChangesUsermod build and workflow
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@platformio.ini`:
- Line 717: The generic [env:usermods] configuration is leaking a touch pin
default into every custom_usermods build. Remove TOUCH_CS from the shared
usermods env and move it into the specific environment that actually needs that
wiring, using the relevant env block in platformio.ini so other usermods can
define their own pin settings.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 2daaed02-dbe9-41a8-99ea-1b1c63bc2710
📒 Files selected for processing (2)
platformio.iniusermods/platformio_override.usermods.ini
| extends = env:esp32dev | ||
| build_flags = ${common.build_flags} ${esp32_idf_V4.build_flags} -D WLED_RELEASE_NAME=\"ESP32_USERMODS\" | ||
| -DTOUCH_CS=9 -DWLED_USE_SD_SPI ;; help a few usermods that require special flags to compile | ||
| -DTOUCH_CS=9 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== platformio.ini line count =="
wc -l platformio.ini
echo
echo "== around referenced line 717 =="
nl -ba platformio.ini | sed -n '690,740p'
echo
echo "== all TOUCH_CS occurrences =="
rg -n "TOUCH_CS|custom_usermods|\\[env:usermods\\]|\\[env:" platformio.ini
echo
echo "== env headers around usermods =="
python3 - <<'PY'
from pathlib import Path
text = Path('platformio.ini').read_text().splitlines()
for i, line in enumerate(text, 1):
if line.strip().startswith('[env:') or 'TOUCH_CS' in line or 'custom_usermods' in line:
start = max(1, i-3)
end = min(len(text), i+3)
print(f"\n--- lines {start}-{end} ---")
for j in range(start, end+1):
print(f"{j:4d}: {text[j-1]}")
PYRepository: wled/WLED
Length of output: 272
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== platformio.ini context around TOUCH_CS =="
nl -ba platformio.ini | sed -n '700,730p'
echo
echo "== all env headers and custom_usermods references =="
rg -n "^\[env:|custom_usermods|TOUCH_CS" platformio.ini
echo
echo "== nearby override envs if present =="
python3 - <<'PY'
from pathlib import Path
lines = Path('platformio.ini').read_text().splitlines()
for i, line in enumerate(lines, 1):
if line.strip().startswith('[env:') and ('usermods' in line.lower() or 'override' in line.lower() or 'touch' in line.lower()):
start = max(1, i-2)
end = min(len(lines), i+18)
print(f"\n--- {i}: {line} ---")
for j in range(start, end+1):
print(f"{j:4d}: {lines[j-1]}")
PYRepository: wled/WLED
Length of output: 232
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== lines 700-730 with line numbers =="
awk 'NR>=700 && NR<=730 { printf "%4d: %s\n", NR, $0 }' platformio.ini
echo
echo "== all occurrences of TOUCH_CS, custom_usermods, and relevant env headers =="
python3 - <<'PY'
from pathlib import Path
lines = Path('platformio.ini').read_text().splitlines()
for i, line in enumerate(lines, 1):
if 'TOUCH_CS' in line or 'custom_usermods' in line or line.strip().startswith('[env:'):
print(f"{i:4d}: {line}")
PY
echo
echo "== locate [env:usermods] block =="
python3 - <<'PY'
from pathlib import Path
lines = Path('platformio.ini').read_text().splitlines()
start = None
for i, line in enumerate(lines, 1):
if line.strip() == '[env:usermods]':
start = i
break
if start is None:
print("missing [env:usermods]")
raise SystemExit(0)
end = len(lines)
for j in range(start + 1, len(lines) + 1):
if lines[j-1].startswith('[env:') and j != start:
end = j - 1
break
for j in range(start, min(end, start + 40) + 1):
print(f"{j:4d}: {lines[j-1]}")
PYRepository: wled/WLED
Length of output: 5366
Keep [env:usermods] generic.
TOUCH_CS=9 in [env:usermods] forces every custom_usermods = * build to inherit the same touch pin. Move it to the specific env that needs it so usermods with different wiring don't pick up the wrong default.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platformio.ini` at line 717, The generic [env:usermods] configuration is
leaking a touch pin default into every custom_usermods build. Remove TOUCH_CS
from the shared usermods env and move it into the specific environment that
actually needs that wiring, using the relevant env block in platformio.ini so
other usermods can define their own pin settings.
Source: Path instructions
There was a problem hiding this comment.
@willmmiles -DTOUCH_CS=9 is actually an older "workaround" for making TFT_eSPI based usermods compile in the CI workflow. Not sure if we should keep this flag?
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n "TOUCH_CS" --type=cpp --type=ini -g '*.ini' -g '*.h' -g '*.cpp' . || true
rg -n "TOUCH_CS" .Length of output: 331
@softhack007, I searched the repo and TOUCH_CS appears only in platformio.ini (Line 717) — it's not referenced anywhere in the WLED core .cpp/.h sources. That confirms it's purely a compile-time define consumed by an external library's config (likely TFT_eSPI's User_Setup.h/pin-select macros), not something WLED itself depends on.
Given that, and consistent with this PR's stated goal of keeping the shared [env:usermods] environment free of usermod-specific flags:
- If there's currently no usermod in-tree that still needs
TOUCH_CS=9to compile in CI, it's probably safe to drop it entirely from[env:usermods]. - If some TFT_eSPI-based usermod does still need it, it should move into that usermod's own
platformio_override.ini.sample(the same pattern being introduced forWLED_USE_SD_SPI/SD_Card andPWM_fanin this PR), rather than leaking a pin default into everycustom_usermods = *build.
I'll leave the final call to you/willmmiles since you have more context on which usermods currently rely on this workaround in CI.
🧠 Learnings used
Learnt from: netmindz
Repo: wled/WLED PR: 5311
File: platformio.ini:395-395
Timestamp: 2026-01-31T18:19:28.320Z
Learning: In platformio.ini for WLED, understand that usermods can be pulled as out-of-tree dependencies via lib_deps (external repositories). The custom_usermods setting controls only in-tree usermods; setting custom_usermods = (empty) disables in-tree usermods but does not disable out-of-tree usermods included through library dependencies.
Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: platformio.ini:486-491
Timestamp: 2026-02-10T13:52:36.924Z
Learning: In PlatformIO projects, prefer using build_unflags in the PlatformIO configuration to remove inherited -D defines rather than using GCC's -U option. The -U approach is order-dependent and may be unreliable if the build command order is not guaranteed by PlatformIO. Use build_unflags in platformio.ini to explicitly remove inherited build flags for more robust and maintainable builds.
Learnt from: softhack007
Repo: wled/WLED PR: 5456
File: platformio.ini:788-850
Timestamp: 2026-03-31T13:31:01.488Z
Learning: For PlatformIO projects using `platform = pioarduino/platform-espressif32` with dual frameworks (`framework = arduino, espidf`), do not require an explicit `board_build.sdkconfig = sdkconfig.<env_name>` setting. `sdkconfig.<env_name>` (e.g., `sdkconfig.esp32s3_matter_wifi`) is a per-environment build artifact generated by pioarduino from merged board defaults plus the project-root `sdkconfig.defaults`. The project-root `sdkconfig.defaults` is automatically loaded by ESP-IDF’s CMake build, so the absence of `board_build.sdkconfig` should not be flagged as a missing configuration.
Learnt from: softhack007
Repo: wled/WLED PR: 5456
File: platformio.ini:788-850
Timestamp: 2026-03-31T13:31:01.488Z
Learning: For PlatformIO projects using `pioarduino/platform-espressif32` with dual framework (`framework = arduino, espidf`), treat `sdkconfig.<env_name>` (e.g., `sdkconfig.esp32s3_matter_wifi`) as a per-environment build artifact generated in the project root. PlatformIO will create it from `sdkconfig.defaults` on first build if it doesn’t exist, and will reuse the existing file on subsequent builds. In code review, do not recommend setting `board_build.sdkconfig = sdkconfig.<env_name>` because that file is an output, not required input. Only use `board_build.cmake_extra_args = -DSDKCONFIG_DEFAULTS=...` to select different defaults files when different environments truly need different SDK config defaults. As a sanity check, if `sdkconfig.<env_name>` is deleted and a rebuild regenerates it with the same content, that indicates `sdkconfig.defaults` is the correct source of truth.
Learnt from: netmindz
Repo: wled/WLED PR: 5543
File: platformio.ini:133-136
Timestamp: 2026-04-26T09:03:12.551Z
Learning: For WLED platformio.ini files: do not mark the audioreactive usermod as “unsupported” for ESP8266 build environments. While ESP8266 can’t process audio locally, it may still receive audioreactive sync data over the network (e.g., from an ESP32 or other source), so the outdated readme note about “ESP8266 is not supported” should be interpreted as only local audio processing. Reviewers should allow audioreactive to be included in ESP8266 environments in platformio.ini when network sync-receive is being used.
Learnt from: softhack007
Repo: wled/WLED PR: 5692
File: platformio.ini:798-799
Timestamp: 2026-06-20T15:08:04.789Z
Learning: For PlatformIO INI files, validate variable interpolation syntax as `${section_name.variable}` where `section_name` is the exact literal section header text (including any `env:` prefix for build environments like `[env:some_name]`). This refers to INI section data, not OS/system environment variables. Therefore, `${env:some_name.variable}` is correct for values in `[env:some_name]` (e.g., `${env:esp32S3_wroom2_32MB.build_unflags}` references `build_unflags` from that `[env:esp32S3_wroom2_32MB]` section); do not flag it as incorrect interpolation.
There was a problem hiding this comment.
I don't think it's actually necessary. TFT_eSPI generates warnings to indicate that the touch subsystem is disabled without it, but that's normal and expected if you don't actually have a touch screen!
I'm almost done the PR for the TFT_eSPI shim anyways. It's been another one where CodeRabbit has been pretty good at finding issues before I push. ;)
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
|
@willmmiles I agree to the principle. The changes were meant to solve a problem with the CI scripts that trigger for usermod changes, especially PR #5679. I've added a custom platformio_override.ini.sample to the SD_Card PR. The CI build used that, but then it still ran the "standard" usermod build targets, in addition to the ones listed inside the usermod folder. I was (wrongly?) assuming this is intended behaviour. The ultimate goal should be that all CI builds are passing, unless there are real errors in the code. So it seems that our usermod-specific CI magic needs to be fixed, too? 
|
Yeah, I'd figured. Generally I'd expect that changes necessary to support a specific PR would be pushed on the PR branch instead of directly to main, though? On the off chance there's some dev with a different opinion .. ;)
In the specific case of #5679, I think the PR is in error (and I'll comment there). IMO it's poor practice to pass module settings using Nevertheless I believe there will be a use case for mandatory environment changes (cf. discusson on #5649) -- so yes, I agree that we probably want to add an exclusion to the CI for modules with specialized environment overrides. I'll add that here. |
Well, in this case i've pushed a change to main, because the overall CI build appeared to have an issue.
👍 |
|
@willmmiles in general, let's use the next team TelCo to discuss our policy for "pushing to main". Right now we still have a very stable My suggestion for the future would be:
that will move us more towards "trunk-based development" -> to be discussed. |
The usermod CI previously ran two parallel tracks: a "plain" build (get_usermod_envs + build) and a separate "custom env" build (get_custom_build_envs + build_custom) for usermods needing bespoke PlatformIO settings. This duplicated most of the gather/build logic. Merge them into a single get_usermod_envs + build pipeline. For each changed usermod, if it supplies a sample ini, use it; otherwise build with the reference platformio_override.usermods.ini. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Avoid interpolating GitHub Actions variables directly in to scripts. H/t @coderabbitai
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/build.yml (1)
79-85: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsistent with usermods.yml pattern; consider hoisting to job-level env.
The
BUILD_ENVenv block is duplicated identically across the "Build firmware" and "Get artifact name from bin filename" steps. Since both steps reference the same value derived frommatrix.environment, moving it to a job-levelenv:would eliminate the duplication.♻️ Optional refactor
build: name: Build Environments runs-on: ubuntu-latest needs: get_default_envs strategy: fail-fast: false matrix: environment: ${{ fromJSON(needs.get_default_envs.outputs.environments) }} + env: + BUILD_ENV: ${{ matrix.environment }} steps: ... - name: Build firmware - env: - BUILD_ENV: ${{ matrix.environment }} run: pio run -e "$BUILD_ENV" - name: Get artifact name from bin filename id: artifact_name - env: - BUILD_ENV: ${{ matrix.environment }} run: |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/build.yml around lines 79 - 85, The BUILD_ENV environment variable is duplicated across the Build firmware and Get artifact name from bin filename steps in the workflow. Hoist BUILD_ENV to the job-level env for the job that contains these steps, keeping the value sourced from matrix.environment, and remove the repeated step-level env blocks so both steps inherit the same setting.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/build.yml:
- Around line 79-85: The BUILD_ENV environment variable is duplicated across the
Build firmware and Get artifact name from bin filename steps in the workflow.
Hoist BUILD_ENV to the job-level env for the job that contains these steps,
keeping the value sourced from matrix.environment, and remove the repeated
step-level env blocks so both steps inherit the same setting.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 99f11f04-f882-4e3b-8a48-4a8e534d581b
📒 Files selected for processing (2)
.github/workflows/build.yml.github/workflows/usermods.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/usermods.yml
|
@willmmiles ready to merge? Or do you still work on improving the PR? |
|
Thanks quite a long thread and diff so I need a bit of time to catch up |
The rabbit is happy now, but I'm happy to wait for @netmindz review. |
3 participants
The global usermod test build environments should not be carrying build flags specific to any usermod. If a usermod requires special build flags for test building, it should supply a
platformio_override.ini.samplewith an appropriate setup (see #5649).Summary by CodeRabbit