Skip to content

Fold suppression-guard.yml's NOLINT job into drift-guard.yml once #614 lands #633

Description

@Yaraslaut

Summary

PR #631 adds scripts/check_nolint_directives.sh (the #627 gate: a
NOLINTNEXTLINE that cannot take effect) and wires it into a new workflow
file, .github/workflows/suppression-guard.yml.

It should be a job in .github/workflows/drift-guard.yml instead. That file's
own header states its remit — "Every job here is fast and dependency-free; none
of them compiles anything"
— and this job is exactly that: two bash scripts over
~700 source files, a self-test and a scan, no compiler, no Qt, no build tree.

It is in its own file only because drift-guard.yml was held by open PR #614
when #631 was pushed, and ci.yml by open PR #623. Both were still open at that
point, so there was no uncontended home.

What to do

  1. Move the nolint-lint job from .github/workflows/suppression-guard.yml into
    .github/workflows/drift-guard.yml as a job (or as two steps on an existing
    fast job there, alongside the spec-citation and CI-clang-pin lints, which is
    the shape those already take).
  2. Delete .github/workflows/suppression-guard.yml.
  3. Delete the "WHY THIS IS ITS OWN WORKFLOW" paragraph from the header comment
    and carry the rest of it — the explanation of the hazard, and the note about
    the deliberate anchoring residual — to wherever the job lands.

Nothing about the gate's behaviour changes. The two scripts, the fixtures under
tests/lint/nolint_directives/, and the self-test-then-gate ordering all move
unaltered.

Verification status: not applicable yet — this is a follow-up, not a defect

Nothing is broken. The gate runs and is non-vacuous as it stands; PR #631 carries
the measurements (it reproduces #627's four sites from unmodified master, and
fails on a re-wrapped directive). This issue records a placement decision that
was forced by contention and should be revisited once the contention clears, so
that the reason does not survive only as a comment in a file nobody re-reads.

What I did not verify: whether adding a workflow file has any cost beyond the
job itself
— a separate workflow is a separate queue entry and a separate
required-check name, and I did not check whether branch protection lists checks
by name. If it does, moving the job will rename its check and branch protection
will need updating in the same change.

What would change the verdict

Close this when the job runs from drift-guard.yml and
suppression-guard.yml no longer exists.

Close it as wontfix instead if someone argues the suppression gate is a
distinct enough concern to keep its own workflow — that is a legitimate position,
it is just not the one the placement was chosen for.

Related

Activity

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions