dgp1130
commented
3 years ago After a lot of debugging, I finally got this good enough to be considered done for now. Documented how to use the GitHub action here. Releases still require a manual start with a semver input but most of the rest is handled automatically.
The debugging process created a whole bunch of rules_prerender@0.0.2-releasetest* packages, but I don't think there's too much of an issue with that since they are all 0.0.x versions anyways.
I also found an action to create a release in GitHub and tag the commit, which is useful to correlate source code state to a particular NPM version. This is also a good place to put in a changelog / other useful info about the release.
We should maybe consider using semantic commits to auto-generate the changelog, but that requires a little more tooling that I'm not familiar with and don't want to bother with at the moment. I also hate the fix(thing): ... format, but I'm not sure if there are other options.
There were a number of debugging commits necessary to make this work, but I'm pretty sure I forgot to add Refs #14 to all of them. The full set should be between dd7a61de5630d1581be7de8063d291f193cdc851..5a71b5cd0e180b028b7ccf854fef30beae603bf6. You can view their entirety with git log 2870fae..5a71b5c.
We have a release script in the form of
//:pkg.publish, although it still requires the package to be built and published on a developer machine. Although Bazel mostly isolates itself from the external OS environment, it is possible for the environment to leak in to builds in a few different ways. Deploying from a GitHub actions CI would enable us to avoid that problem and require that tests pass before a publish.Rather than making versions publish automatically, we could simply have a manual action which takes a version number as an input and then publishes the package at that version. That is likely good enough for now.