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
CI: Add audit steps for formulae and casks #15047
CI: Add audit steps for formulae and casks #15047
Conversation
Now the steps that say they run on all taps are after the one where we set up all taps.
Well well well, look what we've got here. |
Not able to reproduce locally. Probably has something to do with running these audits on Linux and it not being able to decide which
That's probably why it wasn't set up like this before. |
Thanks @apainintheneck! Compared to https://github.com/Homebrew/brew/actions/runs/4506520721/jobs/7933410010?pr=15046: this seems to slow things down a lot. I don't think it makes sense to rely on Note that even before this: Obviously I'd rather we ran more tests more often but, given Linux parallelisation is basically free, I think it makes sense to split out a new job here, perhaps doing just |
Looks like running the audit on MacOS pulls in other proprietary taps that have been installed there so I'll need to specify which ones should be included manually. Also, the tap-syntax step still took around 11 minutes even without the audit. If we're running The new tap-audit step took 16 minutes but that might partially be related to auditing formulae and casks in other taps. I'll rerun it but it might end up being too slow to be worth it. In a pinch we could consider just running the cask stuff on MacOS and the formula stuff on Linux. |
f5d1ec0
to
466e0b2
Compare
This will reduce the time it takes for the tap-syntax job to complete (currently that is the slowest one) and will allow us to audit casks as well as formulae (casks weren't getting audited before in CI).
466e0b2
to
91c0723
Compare
Still quite slow. It failed after the |
This would make sense to me! |
There will be one for casks which runs on MacOS and the other for formulae which runs on Linux.
So now it seems to run pretty well after creating two new audit jobs, one for casks on MacOS and another for formulae on Linux.
TLDR: It adds 15 minutes to the total runtime but the two new jobs are run in parallel so it actually takes less time for the user. The tap-syntax job now takes around 11 minutes instead of 12 minutes previously. |
run: brew readall --aliases homebrew/core | ||
|
||
- name: Run brew audit --skip-style on homebrew/core | ||
run: brew audit --skip-style --except=version --display-failures-only --tap=homebrew/core |
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.
Does it make sense to use --display-failures-only
here? We used to only use it for the general audit and not the one of homebrew/core
. I'm going to rerun it without this option and see if it takes longer to complete.
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.
Seems to run at the same speed so I think it should be fine without it.
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.
It does end up being kind of noisy on the cask side though.
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.
@apainintheneck Yeh, let's definitely do --display-failures-only
here, it's incredibly difficult to find the actual error otherwise when there's failures.
IMO --display-failures-only
shouldn't even be a valid option, we should deprecate it at the next major/minor release and instead use --strict
like we do with formula audits.
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.
That's an interesting point. I'll remove that commit and then this should be good.
@apainintheneck Great work! We've historically had some issues with macOS worker parallelisation but these seem to be gone now. Just a heads up in case we need to adjust this in future. |
ded4bd6
to
7c5e986
Compare
Thanks again @apainintheneck! |
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?Now the steps that say they run on all taps are after the one where we set up all taps. This might have been done on purpose before for performance reasons though. I'm not sure.