Repository navigation
Description
Context
Follow-up to the #974 close-out. #974 was closed after verifying the explicit round-2 sub-issues (#966/#986, #970, #953, #954, #960, #964), but a broader audit found remaining tracker debt around the original #942/#974 performance/CI thread.
This issue exists so those leftovers are visible and actionable instead of being buried in #974/#990 close-out comments.
Investigation sub-issues
Work these one by one. Each item should end with either the referenced issue closed with concrete evidence, or a narrower follow-up issue filed and linked here.
- perf(build): framework libs (~150s) recompiled per project; core cache never hydrates #952 - Verify the fw-libs/core-cache tracker against fix(build): ESP32 sketch+core compiles hit zccache cross-project (#966) #985/fix(build): route framework-lib compiles through embedded zccache — fw-libs cross-project hit (#986) #987/perf(build): fw-lib (framework library) object compiles still miss zccache cross-project #986. Confirm whether warm fresh-project
fw-libsnow meets the <=5s target from the meta: profiling-driven build performance burndown (Docker Linux, NightDriverStrip, cold vs hot cache) #942 harness and decide whether the remainingcore-cache-hydrateconcern is obsolete, still valid, or needs a narrower follow-up before perf(build): framework libs (~150s) recompiled per project; core cache never hydrates #952 is closed. - perf(build): first rebuild after a cold build recompiles once (signature drift between cold and steady state) #957 - Verify the first-rebuild-after-cold tracker against fix(build): don't treat depfile's own mtime as stale → no more first-rebuild recompile (#957) #971. Confirm the root cause, before/after numbers, and whether the first no-change rebuild after cold is now <=10s; then close perf(build): first rebuild after a cold build recompiles once (signature drift between cold and steady state) #957 or update it with the still-failing case.
- Dylint CI gate is red on main (driver build_library failure) — lints are not enforcing #939 - Verify the old Dylint red-gate tracker against ci(dylint): Dylint job is red on main — alias-loop workaround fails, so NO custom lints are enforced #964/ci(dylint): wire dylint-link for all lint crates so libs get @toolchain names (#964) #989/fix(dylint): clean up violations after dylint-link rollout #991 and current
main. Confirm the Dylint workflow is green and actually enforcing custom lints, then close Dylint CI gate is red on main (driver build_library failure) — lints are not enforcing #939 as superseded/resolved or split out the remaining branch-protection/required-status-check work. - PR fix(dylint): clean up violations after dylint-link rollout #991 Windows check cancellation - Investigate the merged PR's
Check (windows-latest)cancellation after ~30m19s: https://github.com/FastLED/fbuild/actions/runs/28844571221/job/85553518607. Determine whether this is the known full-workspace Windows timeout or a regression from fix(dylint): clean up violations after dylint-link rollout #991, then either file/attach a dedicated issue or rerun/fix until the Windows check is green.
Findings
#952 - fw-libs/core-cache tracker is still open
#952 was part of #942 and says warm fresh-project fw-libs should drop from ~150s to <=5s and core-cache-hydrate should hit. Later comments say #966/#986 should deliver the real fw-libs win, and #974's close-out says #966/#986 are resolved, including fw-libs routed through embedded zccache at ~152s -> ~2.2s.
Remaining action: verify whether #952's acceptance criteria are now satisfied by #985/#987/#986 and close it with the measurement evidence, or split any still-real core-cache-hydrate concern into a narrower follow-up before closing #952.
#957 - first-rebuild-after-cold tracker is still open
#942's final report says #957 was fixed by PR #971 and that first-rebuild-after-cold is now a true no-op, but #957 itself is still open.
Remaining action: verify the #971 evidence against #957's acceptance criteria and close #957 if proven, or update it with the missing work if the fix was incomplete.
#939 - older Dylint red-gate issue is still open
#939 reports the Dylint gate red on main and custom lints not enforcing. #964/#989/#991 appear to supersede it: PR #991 shows Dylint passing in 19m12s and #964 is closed. However #939 also asks whether Dylint should be a required status check, which was not explicitly closed out.
Remaining action: verify Dylint is green on current main, close #939 as superseded/resolved by #964/#989/#991 if appropriate, and either document that Dylint is already required or file a separate branch-protection follow-up if it is not.
PR #991 - Windows check still failed/cancelled after merge
PR #991 merged with Dylint green, but Check (windows-latest) on the merged PR check rollup failed/cancelled after ~30m19s: https://github.com/FastLED/fbuild/actions/runs/28844571221/job/85553518607
#990 noted this as a CI note and relied on local Windows/Docker validation for touched crates. That may be acceptable for #964's Dylint acceptance criterion, but it is still unresolved CI debt and should be tracked explicitly.
Remaining action: decide whether this is the known full-workspace Windows timeout or a regression from #991, then either file/attach it to the existing Windows CI timeout tracker or fix/rerun until the Windows check is green.
Proposal
Do a tracker-hygiene pass over the residual #942/#974 items:
- Close issues that are genuinely resolved, with concrete links to PRs, measurements, and check runs.
- Split still-real work into smaller issues instead of leaving broad stale trackers open.
- Track the PR fix(dylint): clean up violations after dylint-link rollout #991 Windows check timeout/failure somewhere explicit.
- Leave meta: fbuild build-performance burndown — round 2 (residuals from #942) #974 closed, but treat this issue as the correction rollup for the broader leftover audit.
Acceptance criteria
- perf(build): framework libs (~150s) recompiled per project; core cache never hydrates #952 is either closed with current fw-libs/core-cache evidence or updated/split so any remaining work is specific and current.
- perf(build): first rebuild after a cold build recompiles once (signature drift between cold and steady state) #957 is either closed with fix(build): don't treat depfile's own mtime as stale → no more first-rebuild recompile (#957) #971 verification evidence or updated with the still-failing first-rebuild-after-cold case.
- Dylint CI gate is red on main (driver build_library failure) — lints are not enforcing #939 is either closed as superseded/resolved by ci(dylint): Dylint job is red on main — alias-loop workaround fails, so NO custom lints are enforced #964/ci(dylint): wire dylint-link for all lint crates so libs get @toolchain names (#964) #989/fix(dylint): clean up violations after dylint-link rollout #991 or narrowed to the remaining branch-protection/status-check work.
- The PR fix(dylint): clean up violations after dylint-link rollout #991
Check (windows-latest)cancellation is tracked in an issue or resolved by a green rerun/fix. - meta: fbuild build-performance burndown — round 2 (residuals from #942) #974 has a correction comment pointing here.
Related issues and PRs
- Parent trackers: meta: profiling-driven build performance burndown (Docker Linux, NightDriverStrip, cold vs hot cache) #942, meta: fbuild build-performance burndown — round 2 (residuals from #942) #974, Finish #974 tail: dylint violation cleanup (#964) + cold-pipeline overlap (#953) #990
- Residual open issues: perf(build): framework libs (~150s) recompiled per project; core cache never hydrates #952, perf(build): first rebuild after a cold build recompiles once (signature drift between cold and steady state) #957, Dylint CI gate is red on main (driver build_library failure) — lints are not enforcing #939
- Relevant PRs/checks: fix(build): don't treat depfile's own mtime as stale → no more first-rebuild recompile (#957) #971, fix(build): ESP32 sketch+core compiles hit zccache cross-project (#966) #985, fix(build): route framework-lib compiles through embedded zccache — fw-libs cross-project hit (#986) #987, ci(dylint): wire dylint-link for all lint crates so libs get @toolchain names (#964) #989, fix(dylint): clean up violations after dylint-link rollout #991
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsTriage
Activity
zackees commentedon Jul 7, 2026
Closing this reconciliation issue as complete.
Resolved/split items:
fw-libstarget is resolved by fix(build): route framework-lib compiles through embedded zccache — fw-libs cross-project hit (#986) #987/perf(build): fw-lib (framework library) object compiles still miss zccache cross-project #986, with the meta: profiling-driven build performance burndown (Docker Linux, NightDriverStrip, cold vs hot cache) #942 harness showing warmfw-libs152s -> 2.2s. The remainingcore-cache-hydratequestion is split into perf(build): decide fate of core-cache-hydrate after fw-libs zccache fix #995.build_unflagsasymmetry was tracked in fix(build): rebuild_signature omits build_unflags stripping → persistent recompiles for build_unflags projects #970 and is already closed.zackees/setup-soldr@v0.9.66, explicitly installssoldr0.8.0, and adds a version assertion so the job fails fast if setup installs an older tool. This keeps the 30-minute job budget rather than extending soldr's wait timeout.Local validation for #993:
git diff --checkuv run --no-project python ci/render_workflows.py --checksoldr --version->soldr 0.8.0Main now includes #993 at merge commit 56990d0. Per the close-out instruction, I did not wait for the new remote workflow run after local validation.