npm publishing and deploying to cjquines.com

[pihart]

Resolves #117
Resolves #200 (6603030)
Resolves #201 (04f6cb6)

The npm publish workflow requires the NPM_TOKEN secret to be set to the token received from npm. It will do the build, tests (if present), and publish to npm on the creation of a GitHub release.

The semver workflow listens to merged pull requests with the semver: ***** labels and executes the appropriate npm commands to increment the package version according to the semver change level. It will push this change as a commit. This also creates a git tag, so creating the GitHub release is as simple as (on GitHub web) clicking into the tag and clicking the appropriate button.

I've thought about this quite a bit and feel somewhat strongly that semvers should be based on module compatibility. That is, the level of changes in the public API of any file reflect the semver level. It is reasonable to add a few exceptions in specific cases: if we drastically change the UI even without breaking any APIs, or if we break a large number of JSON files in a meaningful way (usually this also affects the public APIs so it's not a special case), we'd want to create a major version just for developer convenience.

This does not preclude us from having a different semver pattern for the UI, localStorage format, or whatever else; in fact, we should still be doing those.

NOTE: You typically don't want to merge multiple pull requests with such a label immediately after each other. This is because this workflow tries to push a commit, so if workflows are running in parallel, only the first to complete will actually be allowed to push the commit (we don't ever force push). If updating the version for each pull request is important, just wait for the commit from the first PR to be pushed before merging the second PR. Alternatively, if it's only important that a certain version is given after all are merged (which seems to almost always be the case for this repo), just use the semver: no-semver label on all but the highest semver change; this prevents the semver workflow from running on them, so you can merge at whatever speed. (You should still have the semver: ****** labels for documentation.)

Especially once this gets added to the project, please don't push directly to the main branch; always working with PRs allows us to use CI, this semver, and of course reviews. Further, it helps with grouping changes together.

[cjquines]

i don't think this directly works—post-build, the hrefs in index.html are relative to /, which is incorrect, i think? we might need to add a homepage to package.json or do something else to get the right hrefs.

[pihart]

The hrefs/srcs should(?) all be flat; see https://github.com/pihart/qboard/blob/gh-pages/index.html

[cjquines]

ok. i think the rsync might want a --delete. but i'll test it. also, i think this actually needs a username as part of the secrets xp