You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Dylint CI gate is red on main (driver build_library failure) — lints are not enforcing #939
The Dylint workflow has failed on every push to main for at least the last 5 runs (e.g. run 28569368924 on chore(release): … bump 2.3.23 -> 2.3.24). The failure is infrastructure, not a lint finding:
followed by the workflow's @<toolchain> alias-creation retry loop exhausting its attempts:
::error::cargo dylint did not succeed after ${max_attempts} attempts
Consequence — this is not cosmetic
A red gate is zero enforcement. Concrete escape: #935 merged crates/fbuild-deploy/src/probe_rs.rs with two raw std::process::Command::output() calls — exactly the pattern ban_raw_subprocess (#264) exists to block, in a file that is not in its allowlist. The result on Windows was a visible console window flashing on the user's screen during every LPC845 SWD deploy (daemon is windowless → raw console-subsystem child allocates a fresh console), plus no timeout on a probe family famous for wedging. Fixed after the fact in #938.
Every merge while this gate is red can add more of these silently.
Ask
Fix the driver build (dylint::library_packages::build_library — likely the pinned nightly-2026-03-26 toolchain / component set vs cargo-dylint 5.0.0 interaction, or the alias workaround no longer matching what dylint expects).
Once green, run the full suite over the workspace and burn down any violations that accumulated while the gate was red.
Consider making the Dylint workflow a required status check so a red run blocks merges instead of scrolling past.
Closing the Dylint repair portion as resolved by #989 and #991.
#989 fixed the driver/build_library failure by wiring dylint-link for the custom lint crates so cargo-dylint can find the @<toolchain> libraries. #991 then cleaned up the real lint violations exposed once the custom lints were running again. Dylint passed on current main at run 28844614638, and the #991 Dylint check passed in the PR rollup as well.
The remaining policy request from this issue -- making Dylint a required status check -- is split into #994. The branch-protection API currently reports required status checks are not enabled for main, so that is separate admin/configuration work rather than the original red-gate repair.
Activity
fix(config): derive Default for BoardConfig (unblocks #935 probe-rs t…
zackees commentedon Jul 7, 2026
Closing the Dylint repair portion as resolved by #989 and #991.
#989 fixed the driver/build_library failure by wiring
dylint-linkfor the custom lint crates so cargo-dylint can find the@<toolchain>libraries. #991 then cleaned up the real lint violations exposed once the custom lints were running again. Dylint passed on currentmainat run 28844614638, and the #991 Dylint check passed in the PR rollup as well.The remaining policy request from this issue -- making Dylint a required status check -- is split into #994. The branch-protection API currently reports required status checks are not enabled for
main, so that is separate admin/configuration work rather than the original red-gate repair.Refs #992.