Consider ongoing role of Sonatype Guide / OSSIndex given the "free" API limits #8450
Replies: 2 comments 10 replies
-
|
Thanks for starting this important discussion. As always, very well researched and summarized 👍 This is gonna hit my organization hard I think. In order to keep ODC results as stable throughout the day as possible (i.e. avoid that CI pipeline passes but release pipeline 5min later fails with dependency error), we automatically build a dedicated ODC Docker image early every morning. The image extends from
Most projects (100+) will use this image and its data dir throughout the day in their GitLab pipelines. I've been thinking a few times about how to build/use an OSSIndex cache on top of it. The additional complexity and thus stability risk always put me off so far. A recurring idea has been to zip-up the |
Beta Was this translation helpful? Give feedback.
-
|
Is there some documentation fully explaining what additional value the OSS analyzer is providing beyond the other free to use data feeds and APIs? Before I go back to our purchasing group, I'd like to be able to detail how paying for this service will benefit us. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
With the transition to Sonatype Guide there are now pretty restrictive limits on use of the OSSIndex compatiiblity API - 500 “credits” within a 1 month period.
At this stage there does not even appear to be an OSS/community plan to get larger limits for confirmed OSS projects. Maybe they'll introduce one.
Credits and limits
I migrated https://github.com/gocd/gocd/ to Sonatype Guide a couple of weeks back and it has exceeded already.
datadir cache and the 24 hour default OSS index cachemasterI have not found documentation of the credit usage. Anecdotally it seems to be costing me ~22.1 credits for a completely un-cached query of 230 PURLs (195 x
pkg:maven, 26 xpkg:npm, 7 xpkg:javascript, 1 xpkg:gem, 1 xpkg:nuget(?!))Seems to currently cost about 10 component reports per credit, especially if excluding ones that aren't matched to a known component (7 x
pkg:javascriptplus maybe a couple of others)So perhaps 500/credits per month is about 5,000 component reports.
edit: Credit cost confirmed via looking at raw error response:
{ "code": "CREDIT_LIMIT_EXCEEDED", "message": "Insufficient credits for batch of 128 components (requires 12.8 credits, 8.5 available)", "tier": "free", "resetDate": "2026-04-30", "action": { "type": "upgrade", "url": "https://guide.sonatype.com/settings/billing/compare-plans" }, "creditsRequired": 12.8, "creditsRemaining": 8.5, "batchRemediation": "Reduce batch size to 85 components (from 128 requested)" }Improving experience
I think we should discuss what we should do here to help folks manage this; or how ODC should respond.
Here are some thoughts I have:
402 Payment Requiredlike we do for failure to authCache/DirectoryCacheimplementation, it is hardcoded totry-cache --> if-null-try-remotewithout any ability to use more complex semantics (e.g decoupling check-for-new vs expire-stale by serving stale/expired entries for longer if remote retrieval fails).analyzer.ossindex.remote-error.warn-only = [429, 402]or= [TOO_MANY_REQUESTS, PAYMENT_REQUIRED]pkg:javascript?Any other ideas for what we could do here, preferably to reduce the # of API calls? WDYT @jeremylong @marcelstoer @nhumblot
Beta Was this translation helpful? Give feedback.
All reactions