Ridiculous low limit on SARIF “runs” #1488
Comments
|
Thank you for your inquiry. We had a discussion internally and determined that it is safe to bump the limit to 20 runs. This change will be rolling out in the near future. Please keep an eye on CHANGELOG.md. |
|
Andrew Eisenberg dixit:
Thank you for your inquiry. We had a discussion internally and
determined that it is safe to bump the limit to 20 runs. This change
Thank you!
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
|
|
Great to see the limit increased, but its still too low. For us the limit of 20 is actually a dealbreaker as well. And my company is not alone. And after some Googling, I found folks that were much more patient than I am even split their pipeline up into an entire matrix of chunks to work around the same limitation: https://github.com/vmware-tanzu/community-edition/actions/runs/2253393437/workflow . Monorepos are a thing and 20 is just too limited. And it's also just a very unnecessary constraint. It isn't actually considering the number of violations inside the check run or the file size or any meaningful metric that actually affects the “complexity” or “processing time”. It seems a typical case of premature optimization. So far my support tickets and talks to my solutions engineer/sales rep have not been particularly fruitful. I know this is just the issue tracker for the action and not the backend, but hopefully we can get this constraint lifted one day. |
Prevents issues with SARIF limit on codeql, see github/codeql-action#1488
Prevents issues with SARIF limit on codeql, see github/codeql-action#1488
Unfortunately, this is a showstopper for using the Codacy tool, which runs a plethora of scanners, each of which reports individually:
codacy/codacy-analysis-cli-action#95
None of the discussed workarounds are usable: the one from #1381 fails here because the merge command actually splits up runs; it also removes some so it works-ish for now, but it has the same problems as the other workaround I added: using
jqto remove runs with empty results from the SARIF file. This cannot be used because then, the old reports that are now fixed never go away.The text was updated successfully, but these errors were encountered: