Automated Pre-release builds

[josephjclark]

Overview

This PR enables adaptor release candidates to be published to npm with the @next tag and a pre-release version number.

This in turn allows us to test adaptors in Lightning and the CLI without having to release to the public.

Support added to CLI and Worker in: OpenFn/kit#716

Note that this PR supercedes #625

Issue

Closes #585

How it works

The process is basically entirely automated, and every PR will now auto-deploy pre-release builds.

• Create, commit and push a changeset on a feature branch
• Any open, non-draft pull request with changesets will automatically build a pre-release candidate on push
• The version number will be of the form <next-version-number>-next-<commit-sha>, where next-version-number is the number generated by pnpm changeset version
• Builds will be published to npm with the @next tag
• The previous build, if any, will be deprecated
• Repeat on push
• When the actual release is published with @latest, the last @next is deprecated

Strategy

changesets has support for pre-releases - but I'm not a fan (see #625 (comment)).

Instead, I've set up a customised pre-release process. See the prerelease.mjs file to see how it works - it's quite readable.

Test Adaptor

Check out our test adaptor on npm

• The @latest version is 1.0.1
• The @next version is 2.0.0-next-1b37034b
• The previous @next version, deprecated, is 2.0.0-42e3ac8f (the version naming has changed since)

TODO

• Only trigger a pre-release on non-draft PRs
• Maybe use a label or something to control this? idk,I think non-draft PRs is fine
• check errors on deprecate?
• Make sure the readme is up to date
• Disable automation, then raise a PR to re-enable automation, then merge

[josephjclark]

This is working so much better!