[zackees]

Fixes #1662.

Root cause

pioarduino_platform (packages_platform.rs) handled platform_packages overrides, registry @version pins and release-archive URLs. A platform = https://github.com/<o>/<r>.git#<ref> matched none of them, so warn_unhonored_platform_pin logged a warning and built pioarduino stable. The IDF6 request in the issue produced a green SDK 5.5.5 build.

Change

• Repository sources now go through the shared platformio_repository::resolve_cached_source (the path CH32V uses). The ref is resolved to a commit with git ls-remote and installed from archive/<sha>.tar.gz, and the commit lock is reused by later builds. The archive URL carries the commit, so different refs cannot alias a payload.
• A URL pin that is neither an archive nor a repository is now a hard PackageError naming the two supported forms, instead of a silent fallback to stable.
• Dry-run/check provisioning (fetch=false) reports the platform as would-fetch rather than running git ls-remote.

Verification

• New offline tests cover:
  • parsing a repository ref
  • archive and registry pins still not treated as repositories
  • an unresolvable URL is an error
  • a cached commit lock selects that commit's archive with no network
• soldr cargo test -p fbuild-build-esp: 163 pass. Workspace clippy with -D warnings is clean.
• Real end-to-end build with platform = https://github.com/pioarduino/platform-espressif32.git#prep_IDF6 and board = esp32dev:
  • The log shows resolved requested ESP32 platform …#prep_IDF6 to …/archive/f0c3a7bb53a2f6c730d8eed5770a57b7f5c300d5.tar.gz.
  • The build then fails with an explicit error. That branch's platform.json pins tasmota/esptool v5.6.0/esptool-linux-amd64.zip, which returns HTTP 404 upstream. An honest error instead of a stable build is the outcome the issue asks for. Whether the IDF6 stack compiles once upstream publishes that asset is a separate question.

FastLED impact

No board in FastLED's current ci/boards.py uses a .git#ref ESP32 platform. The IDF6 board moved to the 61.04.00-RC1 release zip, and ESP32_IDF_LATEST_PIOARDUINO is set to #develop but no board uses it.

Not covered

Recording the resolved commit and SDK in build_info.json. They are logged only.

Summary by CodeRabbit

• Bug Fixes
  • Platform versions pinned to a repository are now resolved from the platform cache when fetching is enabled.
  • Invalid or unresolvable platform URLs now return an error instead of falling back to the stable platform.
  • Repository pins are ignored when fetching is disabled.

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: FastLED/fbuild
• Branch: fix/1662-esp32-vcs-platform-ref
• File: .coderabbit.yaml
• Commit: 36cae2c
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 6f1dccfa-0378-495e-bfc9-f1979cea5c4d

Commits

Reviewing files that changed from the base of the PR and between eeaac2e and 36cae2c.

Files selected for processing: 1

• crates/fbuild-build-esp/src/esp32/orchestrator/packages_platform.rs

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Walkthrough

ESP32 platform selection now resolves recognized repository references through the platform cache and uses the resolved archive as an override. URL pins that cannot be honored return package errors instead of falling back to the stable platform.

Changes: ESP32 Platform Pin Resolution

Layer / File(s)	Summary
Repository pin resolution and validation crates/fbuild-build-esp/src/esp32/orchestrator/packages_platform.rs	pioarduino_platform resolves repository references when fetching is enabled and uses the resolved archive override. Unsupported URL pins return package errors. Tests cover repository-ref parsing, exclusions, resolution failures, and cached commit archive selection.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Possibly related issues

• FastLED/FastLED#3515: The repository-ref resolution affects the prep_IDF6 platform binding required by this issue; it does not add the issue’s driver tests or hardware validation.

Possibly related PRs

• FastLED/fbuild#1505: Both PRs change ESP32 platform selection in packages_platform.rs; that PR handles registry and archive pins, while this PR adds repository-ref handling.
• FastLED/fbuild#1530: This PR uses the cached-source resolver added by PR #1530 for ESP32 repository platform pins.

Merge Risk: Minimal · up to 36cae

The identified SSH-style pin concern does not prevent supported ESP32 platform pins from resolving. The change is mergeable after normal checks.

Pre-merge checks: 3 · 2

Failed checks: 2 warnings

Check name	Status	Explanation	Resolution
Linked Issues check		Issue #1662 requires the requested VCS ref and dependencies to build against the selected stack, plus build output or metadata that identifies the resolved repository commit and SDK. The changed resol…	Add build output or metadata that records the actual resolved repository commit and SDK. Provide a successful build against the selected VCS stack, or make the unsupported dependency failure explicit and actionable before compilation with t…
Docstring Coverage		Docstring coverage is 30.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 3 passed

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main change: ESP32 builds now honor .git# platform pins instead of using the stable pioarduino platform.
Out of Scope Changes check		The changes are limited to ESP32 platform source selection, repository resolution errors, dry-run behavior, and related tests. These changes directly support issue #1662. No unrelated FastLED build-fi…

Full details: Out of Scope Changes check

Explanation

The changes are limited to ESP32 platform source selection, repository resolution errors, dry-run behavior, and related tests. These changes directly support issue #1662. No unrelated FastLED build-file redesign or annotation/flash optimization work is shown.

Full details: Linked Issues check

Explanation

Issue #1662 requires the requested VCS ref and dependencies to build against the selected stack, plus build output or metadata that identifies the resolved repository commit and SDK. The changed resolver does select a commit-specific archive and returns explicit resolution errors. The reported IDF6 build still stops at an upstream tasmota/esptool HTTP 404, so a build against the selected stack is not established. The PR states that the resolved commit and SDK are logged only and are not recorded in build_info.json; this does not meet the metadata requirement. Archive pins and commit-lock behavior have focused test coverage.

Resolution

Add build output or metadata that records the actual resolved repository commit and SDK. Provide a successful build against the selected VCS stack, or make the unsupported dependency failure explicit and actionable before compilation with the required focused coverage.

Finishing Touches: 💡 1

📝 Generate docstrings: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}