Closed calebcartwright closed 3 years ago
I had a quick look at the stats for this on https://metrics.shields.io and we serve hardly any of these. In the last 24 hours we served 33 requests for the dependabot compatibility badge and I think moving to an explicit from/to version pair makes the already narrow use-case for this even narrower. If we do need to remove it I think it will be low impact
:clock11: When did the problem start? ~5 days ago, November 8th
:camera: Live badge
https://img.shields.io/dependabot/semver/bundler/puma
:wrench: Is the live badge working?
:link: CircleCI link https://app.circleci.com/pipelines/github/badges/daily-tests/1321/workflows/0b53d87a-2480-4b3e-bb3a-22f88e3d9938/jobs/2223
:lady_beetle: Stack trace
:bulb: Possible solution
It seems that the API contract has changed on us and now requires two additional parameters. Obviously our existing requests don't send those new parameters so we're getting 400 responses with complaints about bad requests.
The API now wants both a
previous-version
andnew-version
to be provided in the query params. Part of me wonders if this amounts to an incredibly similar, but technically new data point since it's now between explicit pairs (and I don't know if the prior/original percentage reflected an aggregate for the package, ranges, etc.)https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=react-select&package-manager=npm_and_yarn&previous-version=4.3.1&new-version=5.0.0
I think we can try to follow up with GitHub to see if the old API exists in any shape or form, but if not, then I'd lean towards deprecating the current badge. We could create a "new" badge that has new required route parameters to account for the previous and new versions, though I'm not sure how much utility that will provide for our users given what seems to be an exact version pinning