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
Make the rules guard catch packages leaving an enforced rule and new ratcheted rules, and give each downgrade an open tracking issue #912
The rules guard compares each rule that exists on the base branch with the same rule on the head (check_baselines in scripts/rules/baseline.py). It fails when a baseline count grows, and when a rule moves from enforced or ratcheted to advisory or doc-only, or from enforced to ratcheted, without a [rule.downgrade] reason. Three ways of weakening a rule still pass:
It doesn't compare a rule's enforcer.projects. Moving a package out of an enforced Pyright rule into a new ratcheted rule passes, because a new rule only produces the note "rule … is new".
A new rule can start ratcheted, with a baseline that tolerates violations, and no [rule.downgrade].
A downgrade's reason is free text. Nothing records the work that restores the rule, so a downgrade has no follow-up.
docs/engineering/skills/type-checking.md lists the first gap under "It doesn't check" (#877).
Proposal
A package that an enforced Pyright rule lists on the base branch, and that still exists, must be listed by an enforced Pyright rule on the head. Otherwise the rule that lists it now needs a [rule.downgrade] section. Moving a package between two enforced rules, and deleting the package, pass.
A rule that is new on the head, ratcheted, with a baseline count above 0, needs a [rule.downgrade] section.
[rule.downgrade] requires issue, the number of an open issue in this repository that tracks restoring the rule, next to reason. The guard always checks that it is a positive integer, and checks through the GitHub API that the issue is open. In CI, a missing token or a failed lookup fails the guard. Locally, without a token, the guard prints a note that it didn't check the issue.
The quality-guards job in .github/workflows/pr.yml gives the guard the job's token, with read access to issues.
docs/engineering/skills/type-checking.md and docs/engineering/skills/rules-registry.md describe what the guard now checks.
Activity
Fail when a package leaves an enforced Pyright rule without a downgrade
Require a downgrade for a new rule that starts ratcheted
Separate the issue lookup from the PR description's fix text
Check that each [rule.downgrade] names an open tracking issue
Give the quality guards a token that can read issues
Hold a ratcheted rule's packages to a rule at least as strong
Reject true as an exception's issue number
Name the token variable gh used when a lookup fails
Keep the tracking-issue schema tests away from the real gh
Look tracking issues up only in the repository the workflow runs in
Say what the guard still doesn't check about downgrades
Require an issue number in every [rule.downgrade]
Fail when a package leaves an enforced Pyright rule without a downgrade
Require a downgrade for a new rule that starts ratcheted
Separate the issue lookup from the PR description's fix text
Check that each [rule.downgrade] names an open tracking issue
Give the quality guards a token that can read issues
Hold a ratcheted rule's packages to a rule at least as strong
Reject true as an exception's issue number
Name the token variable gh used when a lookup fails
Keep the tracking-issue schema tests away from the real gh
Look tracking issues up only in the repository the workflow runs in
Say what the guard still doesn't check about downgrades