-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Add audit check #2595
Add audit check #2595
Conversation
An audit warning formatted by |
I activated issues on my fork in order to ensure the issue creating functionality works, and it looks like it does. |
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.
One of the concerns about using actions-rs/audit-check
is that it doesn't seem to support passing options to cargo-audit
(actions-rs/audit-check#132, e.g., we want to silence the warning that net2
is deprecated), but otherwise it looks good to me.
Thanks! |
I'll follow up with another PR when my PR to add an args parameter to audit-check gets accepted 🤞 |
This continues the work started in #2516, adding two workflows to run
cargo audit
on the code and report these failures in a variety of useful ways. The intent is that the closer the code being audited is to being run in production, the louder these checks will complain. In order of increasing severity:A "manual"
cargo audit
check is run on each pr and push event containing changes to anyCargo.toml
in the workspace. This check only fails the job in order to mark a Pull Request as failing.Every day at 02:00 UTC the master branch is audited using the
actions-rs/audit-check
action. When this check fails it will create an issue on github detailing the issue.Cargo.toml
in the workspace the sameactions-rs/audit-check
is run, and if that check fails an issue will be created and a notification will be sent to the Tokio Discord channel (sending to the correct channel still needs to be set up).This set of checks is slightly different from what was discussed in the previous PR, but I think that these checks make sense. We use
actions-rs/audit-check
only in contexts where theGITHUB_TOKEN
will be accessible, so that on failure the action will be able to create an issue on Github. We still want to audit any proposed changes to the dependency tree in pull requests, but we don't need to report this in any extra fashion than blocking a merge.