Publish release branch to npm via Travis

[trvrb]

All that NPM needs is a NPM_TOKEN that can be obtained via the website (see here). This was set as an environment variable in Travis. With this in place, publishing is just npm publish. I appended this to the end of the set of commands that's run on successful build of the release branch.

You can see it working here: https://travis-ci.com/nextstrain/auspice/builds/83951647#L580

@jameshadfield: I struggled with the getting the deploy statement of Travis CI to work previously and ended up preferring simple shell commands.

@tsibley: I see that both augur and CLI require you to manually run twine upload dist/*". I thought better to make this as automated as possible here so we won't forget to publish and make sure we remember to run npm run build before every publish event. Do you see a problem with this? Otherwise, I'd think to move the twine calls to Travis as well.

[tsibley]

I prefer not to use automated publishing, as it doesn't let you manually inspect the dist artifacts or test them locally before they're published. I find this useful, for example, when changing metadata or ignore files (i.e. seeing what files go into the dist) so I can see the generated package metadata or testing changes to the release process itself. These same reasons are why the git refs aren't pushed automatically too.

(For augur and the CLI, would it be more palatable to bundle up the git push and twine commands into ./devel/publish-release so there was a single, static command to use? Perhaps should be separate conversation.)

[tsibley]

Upon re-reading, I'll also note:

so we won't forget to publish

This is pretty easily remedied if it happens; the consequences aren't high. I don't think the incidence will be very high either.

make sure we remember to run npm run build before every publish event

I would think this would be run automatically from the release script or the publish script. (The equivalent in augur and the CLI are, for example.)

[tsibley]

(One more thing: a (small) benefit of publishing releases from our local workstations is that the NPM registry will actually record who uploaded each release, instead of it being the owner of the API key configured for Travis.)

[jameshadfield]

Deploying auspice to nextstrain.org should, in my opinion, also publish to npm.

[tsibley]

Mmm. I see it inverted from that, in a way. Nextstrain.org should, IMO, run a published version of auspice, but I see publishing auspice as separate from deploying to nextstrain.org conceptually. The distinction is maybe less clear when it's just us and nextstrain.org, but it makes more of a difference as there are other folks running auspice servers (which we aim to encourage, I think).

[jameshadfield]

We are currently focused on developing auspice for nextstrain.org, so I believe this PR is the correct direction. In the future, if we decide to change how auspice is "released" (and what this even means), these processes can change.

[tsibley]

I think the nuance of my point about nextstrain.org vs. auspice was lost, probably because of a bad job of explaining it on my part. I started to re-explain it… but it doesn't really matter. For auspice, do what you and Trevor think is right.

[trvrb]

Hmm.... I see your points Tom about releasing to PyPI. I think with this PR, it's actually a question of how James would prefer to keep up with auspice releases to NPM. He's the person doing releases for the most part. I'm happy to have this merged or closed as preferred.

[jameshadfield]

Great. Thanks for both of your input. Perhaps it's good for me to briefly summarise the current release flow (after this PR goes in):

Running ./releaseNewVersion.sh results in a version bump (to master), and then the release branch being brought up to date with the master branch. This then causes (via travis CI) two side effects:

1. the nextstrain.org server (which serves both the static gatsby site and auspice) updates to serve the newly built auspice client code, as well updating the auspice-server-related code which it imports.
2. the release is published to npm