-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Fail "new primer" runs on fatal errors, like "old primer" #6746
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment has been minimized.
This comment has been minimized.
Pull Request Test Coverage Report for Build 2411224946
π - Coveralls |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's the best of both world π
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This will need a preparatory commit on main to make sure all astroid failures are re-raised as a flavor of |
This comment has been minimized.
This comment has been minimized.
π€ According to the primer, this change has no effect on the checked open source code. π€π |
Here's a proof of concept showing a passing CI job on the primer and an Actions warning annotation with the traceback from astroid: Run / 3.8 |
Type of Changes
Description
The old primer did one thing very well -- it failed CI jobs when encountering
fatal
errors during the linting of open source packages, whether caused in new pylint or astroid PRs, or when adding new packages to the primer, or when third-party packages pushed new changes.The new primer needs some analogous functionality -- something beyond the message differ. If some fatal errors "sneak in" (we merge a PR without noticing the change, or we believe it to be related to a different PR, or incompatible PRs are merged, or we add a package, or third-party maintainers publish new commits), we don't want
n
fatal errors on main to silently matchn
fatal errors on a PR and for the comment-bot to stay quiet about it. We want a failure.I persuaded (πͺπ» π ππ» π ) us into running the primer on bleeding-edge astroid, and from the feedback that we want to be careful not to introduce a dependency in pylint's CI on bleeding-edge astroid with respect to failing jobs (because that is more significant than simply the contents of a bot's comments on a PR), I filter those out here and just issue a warning instead.