Resolves #11: Adds pulling from the latest Bluesky OpenAPI spec #12
Conversation
Still maintains local backup as fall-back Will use user supplied values (either in call or as env variables) first before trying to pull from online source.
| @@ -31,15 +32,27 @@ | |||
| supplied-auth | |||
| (str "Bearer " (:access @(:tokens (:opts ctx))))))))}) | |||
|
|
|||
| (defonce local-spec-path "atproto-xrpc-openapi.2024-12-18.json") | |||
| (defonce bsky-spec-url "https://raw.githubusercontent.com/bluesky-social/bsky-docs/main/atproto-openapi-types/spec/api.json") | |||
|
|
|||
There was a problem hiding this comment.
These could also be made into local names in build-config's let. 🤙
|
Hey @hierophantos, thanks for the PR! I wanted to just clarify a bit regarding #11. That issue is about keeping the OpenAPI spec we're vendoring up to date, rather than allowing the user to specify a different spec (this is already possible by passing an URL or different file path as So the solution I'm imagining here is some kind of script outside of the main code base, that would compare the latest spec provided by the Bluesky team with the version we're vendoring, and somehow update it in our own repository. This could run either locally on a developer's machine, or as part of a CI pipeline (in GitHub Actions for example). It would need to somehow guard against unexpected changes in the official spec breaking compatibility. This could be done by running some unit tests against the updated spec, or by automatically creating a PR with the changes and letting someone review them. Would you be interested in implementing something like this? |
|
Ah, yep! Closing! ;-) |
…enAPI Spec Daily
Still maintains local backup as fall-back
Will use user supplied values (either in call or as env variables) first before trying to pull from online source.