-
Notifications
You must be signed in to change notification settings - Fork 231
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
Provide an output that can be used in later steps to avoid duplicate runs #412
Comments
As a consumer of the trivy findings, I endorse this request. |
Maybe I'm misunderstanding something here but running trivy twice in the same pipeline job doesn't request a DB twice, does it? |
@simar7 It shouldn't (though it has in recentish runs I think because of now-resolved bug) I try to be a good citizen and have 2 steps in the same job - I have seen many having parallel jobs (for speed). But pushing I am pretty close to throwing out the action anyway now given we have the new setup-trivy action.... its a lot of ugly flag management in yaml-wrapped shell to just use native trivy... but most of my suggestions those suggestions would alleviate the need for that |
The request
As another step towards reducing load on the rate limiting - could you provide an action output that we could use like
result=fail
. This would be decoupled completely from exit code (for which the behavior would remain the same as it is today, depending on the exit-code flag)The background
To explain where this would be useful - our typical flow up to now has been to run Trivy twice in a workflow
if: always()
)to get in SARIF format for upload to GHASWhat would an output solve?
Mainly that we can just start to use
convert
instead of a second run whilst presenting a workflow output that is easy and obvious to an engineer to see their results in a workflow when it fails.To do this now in a less obvious format for the consumer of the workflow I have something like:
The problems with this are:
What would the solution look like
So now the workflow output makes total sense to a consumer when there are findings, you get less requests for the DB because we arent running it twice.
Alternative suggestions
Adding the
convert
command to the action which would also be nice - but I suspect much more work than a simple addition of an output?Allow multiple outputs in a single execution - but you guys already rejected that many times and is the reason you added the excellent
convert
command :)Add a
upload-sarif
flag and you handle the creation of and upload of the sarif directly in the initial execution - also a lot more work but would be niceYou could go bananas with outputs like total-findings, critical-findings, high-findings etc etc
The text was updated successfully, but these errors were encountered: