-
Notifications
You must be signed in to change notification settings - Fork 478
test: use go-vcr to mock osv.dev bulk query calls
#2200
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
Open
G-Rath
wants to merge
29
commits into
google:main
Choose a base branch
from
ackama:test/vcr
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Author
b304d09 to
8a43656
Compare
869d0fd to
6b3c1df
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2200 +/- ##
==========================================
- Coverage 67.95% 67.87% -0.08%
==========================================
Files 172 173 +1
Lines 12821 12895 +74
==========================================
+ Hits 8712 8752 +40
- Misses 3437 3467 +30
- Partials 672 676 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
b08f834 to
8777f4f
Compare
cuixq
approved these changes
Oct 21, 2025
1d5beb7 to
41df179
Compare
another-rex
added a commit
to google/osv.dev
that referenced
this pull request
Nov 2, 2025
Hopefully the readme explains most of this, but at a high-level this introduces a new tool based off `osv-scanner` to make it easy to test API changes. Tests are provided as "cassettes" which we use `go-vcr` to load since that has the bonus benefit of being [compatible with cassettes we'll be using in `osv-scanner`](google/osv-scanner#2200), though we do format the `request.body` to be multi-line so it's easier to understand what the query under test is. --------- Co-authored-by: Rex P <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.



This is an attempt to make our CI easier to work with day-to-day by introducing
go-vcras a proxy to record and replay certain HTTP requests, with our "update snapshots" workflow being updated to also update these records.The idea is this will let us continue effectively testing against real external APIs but let us decide when those external APIs change by way of updating the HTTP records (terms cassettes, in keeping with the VCR metaphor).
For now I've just focused on the osv.dev client, setting up
go-vcrto record interactions with any endpoint aside from/v1/vulns/<id>since those requests have huge responses making the cassettes easily balloon beyond 5mb per file - while these do somewhat frequently change, I'm hoping that their day-to-day changes won't be as noisy and especially considering its the response of the bulk query endpoint that leads to the specific vuln lookups so since they're being recorded things should be a lot more predictable.I've structured things so that a recording client is created per top-level test so that a single cassette is used for any subtests, and a
X-Test-Nameheader is included in each request via a secondhttp.Clientwith a customRoundTripperthat gets created in each subtest wrapping the recording client, which allows us to sort the interactions afterwards giving us a stable diff when regenerating.I have also included a custom hook to remove unneeded headers to both further reduce the noise in diffs and the size of the cassettes overall; the only header I'm on the fence about is the
Dateheader since that relates to caching and its technically possible for code to check that for determining if data should be re-fetched, but I think it's best to omit it for now given its present in every single request (ideally I'd like to have it be updated only when something else changes, but that doesn't seem possible without a lot more work).Finally, one notable downside for us to keep an eye on is with keeping the cassettes up to date: the nature of this functionality means its inherently hard for such a library to determine if a particular record is obsolete or needs to be generated as (among other things) that would most likely require making the request in the first place e.g. if we change what headers are excluded but don't explicitly regenerate everything, I don't think CI will complain - thankfully, the worse case is that this should get caught by our "update snapshots" workflow