Update release workflow

[manzt]

The Github actions configuration for the new monorepo will trigger an automatic release if there is a tagged commit on master that starts with v*.

However, the master branch is protected in this repo and you cannot push directly (therefore it's not possible to trigger the CI release). My preference would be to modify the protection settings on that branch (to allow probably @ilan-gold and @manzt) to push directly to master for this purpose.

[manzt]

Thoughts, @ilan-gold ?

[ilan-gold]

Don't we generally do this via PR's? Why would we need to push directly to main? To get a "tagged commit"? Also didn't we switch to main?

A thought that also just occurred to me - we could let npm run publish + CI handle all this, no? I initially thought that because we were automating demo/docs deployment this strategy wouldn't work but then I remembered there are post-publish options for your package.json. So my proposal would be

1. Have a publish action that runs on all commits to main.
2. publish will always run npm publish on all commits
3. If npm publish fails because the version is not updated, postpublish will not update docs/demo because npm publish returned an error code - otherwise it will.

I can add this if it makes sense.

[manzt]

Don't we generally do this via PR's? Why would we need to push directly to main?

Previously we were manually making releases locally, and then opening PRs to say "hey I've made a release". The changes in #606 now formalize the process. A GH Action is responsible for publishing to NPM & S3. (I'd never made a release before because I didn't have either the npm credentials or aws keys. Now it's as simple as pnpm version patch && git push --follow-tags).

The issue is that the trigger for the release Action is a tagged commit to the master branch.

https://github.com/hms-dbmi/viv/blob/fe397aa6378d7def34956844513fc158008aa57b/.github/workflows/test_and_publish.yml#L87-L88

If merging a PR, this is never triggered (even if you push a tag to GH for the PR).

Also didn't we switch to main?

I would like to change the main branch to main but that's a separate discussion and something I don't believe we have discussed? (Look at the main branch for the repo.)

A thought that also just occurred to me - we could let npm run publish + CI handle all this, no?

The ideal workflow is to have the minimal trigger to have CI run pnpm publish. This is already set up with the GitHub action. The trigger is pnpm version <major|minor|patch> and git push --follow-tags. There is only one step on our end: bump the version, and the push to GitHub. The release action is dependent on all tests/checks passing in CI first, and all that is changed with pnpm version is the package versions and CHANGELOG.md. This type of commit should be totally ok to push directly to main, and IMO choosing a different route adds yet another barrier to the simplicity of making a release. My suggestion was to just restrict who can commit directly to master to both of us.

A different option would be to have a different event trigger a release. i.e, inspect name of the PR when merging and decide to make a release (e.g., if pr name matches semver or a string like RELEASE v0.13.0 ).

[manzt]

The new release workflow is documented in the README.md