enhancement(ci): add checks for pull requests and replace the archived release actions #7

Blocker: yes. Fix this before the server-monitoring work starts. The repository is public. Thus, GitHub Actions on standard GitHub-hosted runners are free for it, and CI does not use the organization's minutes.

Defect

• CI operates only when you push a tag. It only builds the binaries.
• Pull requests get no vet, lint, test or vulnerability checks. The tests from bug: Commands exit with code 0 when they fail, and show incorrect error text #2 do not run automatically.
• The workflow uses actions/create-release@v1 and actions/upload-release-asset@v1. GitHub archived these actions.
• actions/checkout@v3 and actions/setup-go@v4 are old versions. The current versions are v7.
• The release names are Release refs/tags/vX.Y.Z.
• The releases do not include checksums.
• A tag with a pre-release suffix (for example v0.2.0-rc.1) becomes a full release. Then /releases/latest returns it, and installed CLIs update to it.

Cost

• The code will change very much. At this time, no automatic check examines a change before the merge.
• Archived actions get no maintenance. A change on GitHub can stop the release process at any time.
• Without checksums, the installer and the updater cannot examine the downloads (refer to enhancement: Examine release downloads with checksums #9).
• A test tag can send an unfinished version to all servers.

Benefit of the fix

• Each pull request and each push to develop and main gets the same checks as make check.
• The release process uses maintained tools only.
• Each release includes checksums.
• Pre-release tags do not reach the installed CLIs.
• Developers can publish a dev pre-release of a branch and test it on real servers before the merge.

Fix

1. Add a CI workflow for push and pull request events on develop and main. The workflow runs make check (enhancement: Add a Makefile for the build, test, lint and release commands #16) and make release.
2. In the release workflow, use actions/checkout@v7, actions/setup-go@v7 and gh release create. gh is on the runner. Thus, the workflow needs no third-party action.
3. Before the release, run make check. Then run make release with the tag as VERSION.
4. Upload the two tarballs and checksums.txt to each release.
5. main is the release branch. Make sure that a tag without a pre-release suffix is on main. If it is not on main, stop the release.
6. If the tag has a pre-release suffix, create a pre-release. A pre-release tag can come from any branch.
7. Add make dev-release. It tags the current commit as <next minor version>-dev.<short commit> (for example v0.2.0-dev.1a2b3c4) and pushes the tag. It refuses uncommitted changes and commits that are not pushed. It also refuses a commit if its release workflow would publish the tag as a full release.

The test harness (a fake docker script on PATH) is already in #2.

Caution

CAUTION: DO NOT CHANGE THE NAMES OR THE CONTENTS OF THE RELEASE ASSETS. IF YOU CHANGE THEM, THE INSTALLED CLIS CANNOT RUN fly update.

• The updater in v0.1.1 accepts only assets with the name fly-linux-<arch>.tar.gz.
• Each asset must contain a binary with the name fly-linux-<arch>.
• The updater compares tags as text. Thus, each new tag must sort after v0.1.1 as text.
• Keep these rules until all servers use the corrected updater (bug(self-update): correct the version comparison, the HTTP errors and the binary replacement #8).

Completion checks

• Pull requests show the check results.
• A tag push makes a release with the two tarballs and checksums.txt.
• The asset names do not change.
• A tag on a commit that is not on main does not make a release.
• A tag with a pre-release suffix makes a pre-release.
• make dev-release on a branch makes a pre-release, and /releases/latest does not change.