Add publish workflow

[aefhm]

Description

Automatically publish newer versions of different JS packages to NPM if they are not present on the registry already on all pushes to the main branch.

TODO

• Potentially update documentation to reflect the need for a post-merge tag step

[kostko]

Task linked: CU-863h6mt6x Use CI to publish NPM packages on sapphire-paratime repo

[aefhm]

@CedarMist @matevz One alternative is something with more full-fledged change logs such as changesets which pnpm recommends. We don't have such a large monorepo with just 3 packages and mostly a linear development cycle, so I think something lightweight such as this GitHub action is sufficient.

[CedarMist]

The simple github action looks easiest.

[CedarMist]

@aefhm

I don't think doing releases on every main merge will work.

Instead, we need to tag specific releases, and only upon tagging will that specific package get published.

[kostko]

Yeah it should be based on tags, just note that in this repo we are also using tags to automatically release the runtime, so make sure to namespace the tags.

[aefhm]

@aefhm

I don't think doing releases on every main merge will work.

Instead, we need to tag specific releases, and only upon tagging will that specific package get published.

Just clarifying that this specific GitHub action (which would run on every main push) checks to see if the present package version has been published to NPM, and only publishes if not present.

Can definitely switch workflow trigger to a regex based on some name-spaced tag like (Core does go/v0.2202.10), so perhaps clients/js/{{version}} and so on.

[aefhm]

Yeah it should be based on tags, just note that in this repo we are also using tags to automatically release the runtime, so make sure to namespace the tags.

Confirming that by this we mean Git tags? I think/agree we should reserve the use of the release release for the paratime itself. Clients can just live with a trigger from simple Git tag on push.

[CedarMist]

Yup so package specific tags such as:

• contracts/0.2.4
• clients/js/1.1.1

With the Github release reserved for Sapphire releases (e.g. 0.6.4)

[CedarMist]

Always a bit nervous about testing NPM deploys, does that mean the final test is essentially in production?

[aefhm]

Always a bit nervous about testing NPM deploys, does that mean the final test is essentially in production?

More or less 😬. I couldn't test the tag piece (due to GitHub permissions), but we could always take down an NPM package if need be.

The one nice thing about this particular GitHub action versus writing more bare bones script is the release check, and we could always tag a patch first.

[matevz]

Small nit regarding the leading v. Otherwise, I look forward to having this in oasis-sdk repo for the client-sdk/ts-web as well! ;)