[Feature Request] Auto-upload new SDK on every deployment.

[Feverfew]

Is your feature request related to a problem? Please describe. We don't have well-maintained and complete SDK's to help people onboard onto the API.

Describe the solution you'd like Use the OpenAPI schema to autogenerate SDKs for our users.

Describe alternatives you've considered (optional) Code snippets in front-end docs.

Additional context(optional) https://swagger.io/tools/swagger-codegen/

[shu8]

I've created a new repo here: https://github.com/uclapi/uclapi-js-sdk for a JavaScript SDK, auto-generated from the OpenAPI spec.

It just needs auto-publishing to npm now, which I'll hopefully be able to do in the next few days (I don't have access to our npm org at the moment though!).

[shu8]

We're now uploading a JS SDK to npm: https://www.npmjs.com/package/@uclapi/sdk from this repo https://github.com/uclapi/uclapi-js-sdk whenever the spec changes from swagger hub in this repo: https://github.com/uclapi/uclapi-openapi.

Note there's also a manual version change needed in https://github.com/uclapi/uclapi-openapi before the package is updated in npm.

[Feverfew]

We discussed this in the meeting. I'd just like to re-iterate what I said (although there was disagreement with this approach) so we can move the discussion here:

The OpenAPI spec will be held in the repo. Deployment of the new SDK should happen only when the following two conditions are true:

1. The spec has changed.
2. The changed spec has been pushed to uclapi.com

The reason is, is that in terms of SDK, the SDK will only change when the APIs have changed (and been pushed to prod), and so that is the only necessary time to increase the SDK version.

[shu8]

To add on to that, I think we also discussed being able to link GitHub releases directly to deployments, so that when we tag/release a version via GitHub the deployment automatically happens rather than doing it manually.

I think we also were unsure on how to version the API -- it makes sense for the SDK to only change version when the OpenAPI spec changes, but the API versioning should still probably include patches that don't affect the API interface itself?

So maybe we could:

• bump the SDK versions (minor number?) and deploy automatically when we make a new GitHub release
• bump the API version (this versioning might need to be manual, to choose between minor vs patch?) whenever master is pushed to (which is also the staging deployment step)

or something along those lines?

[zipy124]

@shu8 can we close this now?

[shu8]

@zipy124 only the JS sdk is done, it would be nice to create one for Python too/other languages (but could be made a different Issue)