Skip to content

Dylint CI gate is red on main (driver build_library failure) — lints are not enforcing #939

Closed

Description

@zackees

Problem

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:

Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
   1: dylint::library_packages::build_library
   ...
   5: dylint::run_with_name_toolchain_map
   6: dylint::run

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

  1. 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).
  2. Once green, run the full suite over the workspace and burn down any violations that accumulated while the gate was red.
  3. Consider making the Dylint workflow a required status check so a red run blocks merges instead of scrolling past.

Refs

Activity

  1. added a commit that references this issue on Jul 5, 2026
  2. zackees commented on Jul 7, 2026

    @zackees
    MemberAuthor

    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.

    Refs #992.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions