Publish GitHub action

[mattheu]

It would be neat to publish automatically when a new version is tagged.

One reason for this is that any engineer at Human Made could tag a new release without being added to our npm organisation.

I'm not 100% sure of the exact workflow we would like around this. e.g. bumping the version, and pushing the tags. So maybe the instructions around this need a bit of refinement.

NOTE: I've not actually tested this... not totally sure how to do so. I'm not super familiar with github actions.

[tfrommen]

I've just refreshed this with the split-off contribution PR merge.

Personally, I'm not yet sure what the ideal process for this would be. I really like using np.
But we haven't yet decided if we want the complete release process to be able to be done from GitHub, or if some local action is OK. If it is, we could also easily require using np, and the process could be to update the version, push to the default branch, switch to the release branch, build the assets, push, tag, publish to npm, and create a GitHub release. All of that could be automated.

Any thoughts on that? What is the list of "actions" you think you would want to be included in the release process?

[tfrommen]

Given that no regular (external) contributor will ever release a new version of the package, maybe the release process, once finalized, should better be included in the main README instead of this file?

[mattheu]

Happy to put this on the backburner. My main goal here is to make sure everyone can actually contribute to this project easily. Whether that's automated or just having the process documented is fine by me 👍

[tomjn]

But we haven't yet decided if we want the complete release process to be able to be done from GitHub, or if some local action is OK. If it is, we could also easily require using np, and the process could be to update the version, push to the default branch, switch to the release branch, build the assets, push, tag, publish to npm, and create a GitHub release. All of that could be automated.

@tfrommen not everyone at HM has access to the NPM package distribution system or knows how it works, so this is a major barrier to contribution. It's also a perpetual source of future pings pokes and prods for those who can do releases by those who can't. This needs to be automated.

For example, there are improvements in this repo that I want to use but can't because they haven't been released yet. As a result I have a PR and JIRA ticket sitting in limbo since November that I'm powerless to progress as a result. It also means I'm forced to ping/poke/prod to get this moving because there is no automation. To my knowledge we can't just give everybody at HM that access on the npm registry

[tfrommen]

there are improvements in this repo that I want to use but can't because they haven't been released yet. As a result I have a PR and JIRA ticket sitting in limbo since November that I'm powerless to progress

What improvements are you referring to, @tomjn?

All actual code changes should have been released already, since November (see npm).

If you take a look at what has changed since the last tag/release, you will find that this is only documentation, CI config, and a local development npm script.

[tomjn]

@tfrommen I hadn't noticed 0.3 was released though there was still a time when I was blocked by it.

The main point being that a manual process no matter how nice it is, how well documented it is, or how many tools it's simplified by is always a manual process, and requires the intervention of a sub-set of people. It's unclear who those are and when they have capacity for release duties.

Automation means anybody can do it, and I'm not at the mercy of figuring out who can do it, followed by when they can do it, I can just do it myself. Giving me access to publish manually on NPM just shifts the problem to someone else, and it's not a problem that someone who already has access has to contend with.