-
Notifications
You must be signed in to change notification settings - Fork 22
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
Scan images using trivy #289
base: main
Are you sure you want to change the base?
Conversation
I just checked this locally with the
Can't find the |
That is because the trivy scan is part of the |
d6d91ee
to
41910c8
Compare
And I was wrongly assuming that |
9adb95f
to
dcd8091
Compare
7dffd89
to
1e2af6a
Compare
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.
This is a good idea, but I do not think that we should add this to the test suite. Currently we have a bunch of test failures due to this and I don't see how we will ever be all green, there's always going to be an issue somewhere.
But my main issue is this: imagine we have a CVE that we need to fix. But now trivy is red, hence we have an overall test failure, so QA will flag the new build as faulty and they have to manually waive all the failing tests. This is imho not helping when we need to get a fix out.
Open to counter-opinions, but in this state, this is not helping
That's only because of TARGET=ibs-released. I can remove that easily from the testing matrix, but that is entirely unrelated to the rest of your comment because QA is never running with it
trivy will only flag it if the image still contains the CVE, so that's exactly what we'd like to make the check do.
it prevents releasing unfixed images. it doesn't prevent releasing fixed images. |
1e2af6a
to
c37fe23
Compare
No description provided.