Implement GitHub Actions for releases

[ocdtrekkie]

Since we need to install things like WINE and github-release and such to do vagrant-spk releases, and most of the release process is already well-scripted, we should consider making this a GitHub Action.

Currently this repo fails to document or include installation of the github-release tool the release script depends on. Kenton knows the github-release tool he used for the last release is version 0.7.2, and I found https://github.com/aktau/github-release/releases/tag/v0.7.2 which I believe is plausibly the correct one.

[ocdtrekkie]

@abliss After #261, releases will require a commit to release.sh, and I think it’d be safe to trigger the Action on a commit to release.sh since it should only be touched when making a release, and won’t succeed unless the change log is also updated for that new release version and the current date. So even if we edit release.sh prior to a release and cause the Action to fire, a release will not happen.

I am also going to add checks for the two other places the version number is specified to ensure nobody misses one when releasing the app.

[ocdtrekkie]

We may have to use another fork because of github-release/github-release#97 which is the same issue as sandstorm-io/sandstorm#3205

github-release will work for 1.0, it just makes a deprecation warning email I can disregard, but by 1.1, it might not work.

The other option is to switch to https://github.com/github/hub which has a release functionality and is a tool from GitHub. However, the unfortunate news is this would only be a temporary improvement, as GitHub just launched GitHub CLI, which does not yet include the release functionality, but they've suggested that CLI will succeed Hub, so we will have to change it again.

[ocdtrekkie]

I have a lot of notes on how horrible getting 1.0 to fire off my release script.

[ocdtrekkie]

Okay, so, some additional notes from trying to release 1.0:

• wine32 setup completely explodes on Ubuntu 18.04. I ended up using an old 17.04 VM I made for a college class to push the release.
• Inno Setup 6.x did not work with the release script, citing incompatibility with the version of Windows. 5.6.1 is the last release that supports XP, which I ended up pasting into the release script to get it to work. Setting winecfg to Windows 10 also didn't work, so I am guessing the Makefile sets the Wine environment to something obsolete.
• Windows build is broken with new pyinstaller (3.2); investigate pynsist instead #168 states pyinstaller 3.2 breaks the build, and 3.1.1 is pinned in the Makefile.
• We also have Python 2.7.10 pinned in the Makefile, which will be a problem for vagrant-spk should be upgraded to Python 3 #247.
• Unpacking msysgit exploded on my box, because I had a hard time installing/finding something compatible with 7z files. I ended up manually unpacking msysgit.7z.
• I am not sure if the Makefile would've fixed this, but msysgit has an internal folder structure, and things like ssh.exe and a DLL file were expected in the root of the msysgit folder instead. I ended up pasting around some stuff in the msysgit folder until the Makefile accepted it.

I also found the release script a bit fragile and unable to recover from failure at various stages. I ended up commenting out a lot to get the release to fire off. I ended up commenting out the assertion that git was clean, since I had to edit the release script's download location for Inno Setup. When I had a credential issue with GitHub, it was after I had tagged the release (but before I pushed it to GitHub). On a re-run, the tag command failed out the script because it was already tagged, and I ended up commenting out that line too. Prior to commenting out the git clean check, another issue I noticed was a PLATLIB folder created when building Windows was neither gitignored nor cleaned up due to where the script failed, and that then caused the git clean check to fail.

[ocdtrekkie]

It's worth noting we'll have to either install Python 2 on the runner or upgrade vagrant-spk to Python 3: https://github.blog/changelog/2020-02-27-github-actions-breaking-change-python-2-being-removed-from-all-virtual-environments/

[ocdtrekkie]

As of cli/cli#1552, release management is supported by the gh command, so when we modernize this script we should switch to that.

[ocdtrekkie]

I am assigning myself to this because I am trying to set this up, now that I've spent a bunch of time with the Windows build process and release script.

Side note, I thought it'd be cool if we could do actual integration testing with Actions too using the test apps, but they don't intend to let Actions access nested virtualization, which is sad but not shocking.

[ocdtrekkie]

This is extremely adjacent to the project itself, and I suspect would be good for someone without a deep understanding of Sandstorm itself to help with.