chore: add release-please

[JGAntunes]

This PR partially addresses #285. The idea is to provide a way to tag, release and bump the versions of both package.json and swagger.yml files. I tried running some tests on this repo but unfortunately seems like release-please will always create PRs against the mainline. As such I've ran some tests yesterday on a small repo - JGAntunes/actions-playground#1 - testing auto-commit. The idea here is to rely on it as a workaround to bump the swagger.yml file based on package.json version (which is initially done by release-please).

For this to work I'll need to add a secret to the repo (currently don't have access, maybe you can help me witht it @erezrokah?), similar to what we've done, maybe we can usenetlify-bots access token? - netlify/cli#1778 (comment)

[netlify]

✔️ Deploy preview for open-api ready!

🔨 Explore the source changes: f452ce9

🔍 Inspect the deploy logs: https://app.netlify.com/sites/open-api/deploys/60085ddfcc231d00098f3637

😎 Browse the preview: https://deploy-preview-288--open-api.netlify.app

[erezrokah]

For this to work I'll need to add a secret to the repo (currently don't have access, maybe you can help me witht it @erezrokah?), similar to what we've done, maybe we can usenetlify-bots access token? - netlify/cli#1778 (comment)

Thanks @JGAntunes I've added the secret. How are we dealing with generating the go client?

[erezrokah]

Added a few comments, but will delegate to the Backend the rest of the review.

[JGAntunes]

Thanks @JGAntunes I've added the secret. How are we dealing with generating the go client?

I've added a more extensive comment covering that @erezrokah - #285 (comment)

[mraerino]

from a process level this looks fine.

this still expects people to manually regenerate the Go client right?

since this has always been the case this is not a blocker: can we think of a process where PRs are denied when the go code is not up-to-date?
that would also block releases that had this problem (but should not if we never merged PRs with failing checks).

[JGAntunes]

this still expects people to manually regenerate the Go client right?

@mraerino that's correct yes, I've went through a more lengthy boring explanation here - #285 (comment) - but essentially we can come out with an action to verify if new files are generated through make all and haven't been checked in, and fail the build in that case. I would rather have it as a separate PR though. Maybe later on we can improve the automation for generating the go client, but at least that way we would already have some safeguards in place.