Open jeffmendoza opened 4 months ago
Seems reasonable to have a WithTransport()
option which accepts a http.RoundTripper
. Scorecard may still choose to wrap the provided transport with MakeRateLimitedTransport or MakeCensusTransport from https://pkg.go.dev/github.com/ossf/scorecard/v5/clients/githubrepo/roundtripper I'm not sure our GitLab client has an analog.
What interaction would you expect if provided both WithTransport()
and WithRepoClient()
?
Scorecard may still choose to wrap the provided transport with MakeRateLimitedTransport or MakeCensusTransport...
Yep, makes sense
What interaction would you expect if provided both WithTransport() and WithRepoClient()?
Probably shouldn't use both, but I would expect the the passed in RepoClient to be used unmodified and take priority, and the transport from WithTransport to be used elsewhere.
This issue has been marked stale because it has been open for 60 days with no activity.
Is your feature request related to a problem? Please describe.
Transports are the universal way to add middleware in Go. For Scorecard to be used as a library it should accept a transport to be used everywhere. Currently you have to investigate the various client options and create clients with custom transports if that is even possible.
Transports are useful for things like:
auth - github token / deps dev api key / etc. caching logging and tracing adding headers (user agent) retries
Describe the solution you'd like
When running Scorecard as a library, these should all be controllable by the calling program. Scorecard should take a Transport as an option in scorecard.Run() then use that for:
github deps dev ossfuzz osv BP badge ... etc.
Describe alternatives you've considered Current method of creating the different clients where allowed.