Skip to main content

LINT.NO_ACTIVE_RULES — the scope admitted no rule, so nothing was checked

  • Category: safety
  • Level: 0
  • Stability: stable
  • Suites: lint

The combination of --level, --category and your configuration admitted no rule at all. The run completed, examined your migrations, and applied nothing to them.

Without this finding that outcome is byte-for-byte identical to a clean run: no findings, exit code zero, green pipeline. It is the purest form of the silent green this package exists to refuse — and the most convincing one, because everything about it looks like success.

Not a rule, and it says so​

This is a runner notice: no rule produced it, and no rule could, because it states something about the run as a whole rather than about a statement. It carries an id, a message prefix and this documentation URL exactly like a rule's finding, because a reader should not have to know the difference to act on it.

What usually causes it​

  • --level=1 --category=idiom — a real combination with no members, because idiom rules start at level 5.
  • A category name that does not exist. A typo there would otherwise filter to nothing and read as clean, which is why an unknown category is a hard configuration error rather than an empty filter.
  • A preview rule set that nothing opted into, on a project whose only rules were preview.

It moves the exit code​

The run reports misconfiguration rather than clean. That is deliberate: a CI job branching on the exit code would otherwise treat "nothing was checked" as "nothing is wrong", and the finding alone would not stop it — an undetermined result only moves the exit code under strict_undetermined, which you set in config/sqlens.php or get from --profile=ci.

What to do​

Widen the scope, or fix the filter. If the empty scope is intentional — a pipeline stage that only runs security rules, say — then it is not this command you want.