Upload rolling pre-releases

[ahelwer]

Finally got around to this. This sets up rolling pre-release publishing similar to what exists for the TLA+ tools, where the head of the main branch is built and uploaded to a github release for ease of consumption.

This work requires some changes to the repository settings:

1. Create a release environment and constrain it to only be accessible from the main branch
2. Create a new pre-release titled (for example) Version 1.6.0 rolling pre-release or similar
3. Create a fine-grained personal access token with read/write access to releases in the tlaplus/tlapm repo
4. Store the access token in the release environment secrets as TLAPM_RELEASES_AT
5. Define the ROLLING_PRERELEASE_VERSION environment variable in the release environment to be 1.6.0-pre or similar
6. Define the ROLLING_PRERELEASE_GITHUB_NAME environment variable in the release environment to be whatever you called the release in step (2)

If you give me more permissions on this repo I'll do all of that or whoever is reviewing this can do it themselves. I've tested this on my own fork of the TLAPM repo; you can see what the release with uploaded artifacts looks like here: https://github.com/ahelwer/tlapm/releases/tag/1.6.0-pre

This is a good first step to get this working and then later we can add the following features:

1. Update the tag associated with the release to track the head of the main branch
2. Do macOS code signing (ref Sign TLAPS release to be accepted by macOS gatekeeper #46)
3. Upload the releases to the Inria server as well

Ref #92

[ahelwer]

@lemmy Stephan made me an admin of this repo, but it does not appear fine-grained personal access tokens are yet enabled for the tlaplus organization. Would you be able to enable them? Then I can create a PAT scoped only to modify TLAPM releases. Here are the instructions: https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization#restricting-access-by-personal-access-tokens

For token expiration policy I do think it's fine to leave it as unbounded (no expiration) but that's up to you. I believe you can also add the necessity of requesting approval before users can create PATs for repos under the tlaplus org; not sure how that flow works, guess we can try it. I believe PATs created by a user can never exceed the permissions that user already possesses.

[ahelwer]

Actually I just learned about GITHUB_TOKEN so that won't be necessary. Might be useful to enable PATs in general though.