search

google / osv-scanner

Vulnerability scanner written in Go which uses the data provided by https://osv.dev
https://google.github.io/osv-scanner/
Apache License 2.0
6.01k stars 337 forks source link

test: update snapshots and exit codes #1036

Closed G-Rath closed 2 weeks ago

G-Rath commented 2 weeks ago

Someone that knows these tests better should double check that these changes in exit codes mean they're no longer covering what they were meant to

cuixq commented 2 weeks ago

I think we should update cmd/osv-scanner/fixtures/locks-many/alpine.cdx.xml

G-Rath commented 2 weeks ago

Is that something you're ok to pick up? I don't actually know how to generate an sbom 😅 (everytime I try, the CLIs confuse me)

cuixq commented 2 weeks ago

@another-rex could you help to update the fixture?

G-Rath commented 2 weeks ago

(fwiw, it could be worth putting that into a script to make it easier to repeat - even if it's just the raw commands that only work on Rex's local, it'd mean I could clean it up later to make it more repeatable for everyone)

cuixq commented 2 weeks ago

ideally, I would like to run the tests against some mock database, so we don't need to update the fixtures all the time.

codecov-commenter commented 2 weeks ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 65.25%. Comparing base (d857676) to head (dd87a91). Report is 1 commits behind head on main.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #1036 +/- ## ========================================== + Coverage 65.15% 65.25% +0.10% ========================================== Files 149 150 +1 Lines 12434 12497 +63 ========================================== + Hits 8101 8155 +54 - Misses 3874 3881 +7 - Partials 459 461 +2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

G-Rath commented 2 weeks ago

eh that would be nice but then require a lot of different work - something I've been thinking of exploring which could be a useful middleground is creating a workflow that runs say daily to automatically open a PR with snapshot updates.

Another alternative is the osv schema itself could define some kind of "test" ecosystem and then the api could have a bunch of osvs using that ecosystem, with the idea being you can officially represent advisories of different structures for the purposes of testing so they're a lot more controlled