Automate releases with GitHub Actions

[cmsj]

This is mostly me leaving notes for myself, but for this to work, there will need to be some changes in how we commit code to this repo.

tl;dr I'd like to automate the releases using GitHub Actions, so a new release would be built, signed and published any time a new version is tagged in the repo - this would allow @asmagill to do releases as well, and also means we could easily release a lot more often (after each PR merge if we really wanted to).

The downside is that we'll need to get a lot more rigorous about the way we land code, because the Changelog will need to be automatically generated.

My proposed workflow would be:

• No more commits directly to master (which primarily affects me, since I tend to push stuff directly)
• Every release gets a Milestone (I've been a bit spotty about doing that)
• Everything has to be a well-tagged, correctly formatted Pull Request:
  • No more [WIP]/[REVIEW] in the subject, we'd need to switch to using the GitHub "Draft"/"Ready For Review" states to track that, but that's actually helpful because you can't merge a PR that's in the Draft state
  • Every PR should be targeted at a Milestone
  • Every PR needs one (and only one) of the following labels: pr-fix, pr-change, pr-feature, pr-maintenance. These would be used to decide which section of the release notes each PR would be mentioned in (with the exception of Maintenance which would likely be excluded, because it would be stuff like GitHub Actions edits, or fixing build warnings and generally anything that users wouldn't care about).
  • In theory I can add some automation that would automatically add/remove labels that tell us whether or not a PR has the right labels it needs
  • The title of the PR (at the point it is merged) would be the text included in the Changelog
• Ideally we wouldn't even hit the Merge button, but merges would happen via automation when we review a PR positively
  • This seems like it might not be possible, because people can't give an Approve review on their own PRs, and it makes no sense to slow things down by requiring us to review each other's PRs for even the simplest of changes

Notes:

• https://github.com/marketplace/actions/release-drafter looks like interesting automation for generating release notes

[asmagill]

This sounds like a good idea, but a couple of questions:

1) well, more of a request -- examples of "properly done" milestone lists, PRs, etc. This may have to wait til you have it in place, but once you know what will be the "proper way to do things", examples will be helpful 2) what about nightly or development builds?

• Nightly might be too often, but what about a tag that creates a development build (which probably means merging to a development branch in case we end up retracting it, not sure) that we might want to get a little wider testing before making it official?
• If adding a development stream (and corresponding checkbox) to the Sparkle infrastructure would be annoying/difficult/impossible, than just putting the development version into the releases so we can tell people to check "https://github.com/Hammerspoon/hammerspoon/releases" if they want to run an interim build would be sufficient.

[cmsj]

Examples: definitely, I'll need to format a few things "Correctly" so I can test the automations

As for nightly/dev builds - once we have the automation for releases done, it would be very easy to have a signed build generated on almost any event. For development builds, we'd also want to arrange an alternative appcast.xml and perhaps even let people switch between the two in the Hammerspoon prefs.

So yeah, we could have a development build generated for each merged PR (not opened PR, since that would allow anyone to get a signed build with any nefarious code in it).

[cmsj]

For the avoidance of doubt, 0.9.83 is not included in this, we have a bunch of commit history that can't be automagically turned into release notes, but I'd like to start piloting it for 0.9.84.