assemble-distro.yml does not update latest date

[fingolfin]

The action logs from a few minutes ago look fine and as if everything worked.

But the latest release tag is still at the stage of 14 days ago.

This definitely used to work, but at some point I switched to a different GitHub Action for creating / update the release (the previous one was based on Docker which I didn't like). I guess I neglected to properly check after the switch that this case (updating an existing tag) still works...

So the first thing to try is to find the commit where I switched this, and try out using the previous GH action (say on a personal fork of this repo, where one can of course simply switch back and force between older and newer package versions to experiment)

[fingolfin]

So right now we are using softprops/action-gh-release. Looking at https://github.com/softprops/action-gh-release/blob/master/src/github.ts it does have explicit support for updating existing tags, and the messages printed in the log I linked suggest that this code path is being run. Yet the releases did not get updated ... huh? Perhaps there is an error somewhere, which they do not properly propagate??

[fingolfin]

I've inspected the files stored in https://github.com/gap-system/PackageDistro/releases/tag/latest and they were updated! So the uploaded work. Just updating the release resp. tag to point at a new tag did not.

[fingolfin]

Urgh. That package uses OctoKit. From the OctoKit documentation for octokit.rest.repos.updateRelease, discussing the target_commitish argument:

Specifies the commitish value that determines where the Git tag is created from. Can be any branch or commit SHA. Unused if the Git tag already exists. Default: the repository's default branch (usually master).

This in turn is a direct quote from https://docs.github.com/en/rest/reference/releases#update-a-release

I am guessing the crucial bit is "Unused if the Git tag already exists".

[fingolfin]

But as far as I can tell, https://github.com/meeDamian/github-release also uses this API (see https://github.com/meeDamian/github-release/blob/master/entrypoint.sh). Hrm. But I am sure I verified it worked as intended (= update the tag to point to the new commit).

[fingolfin]

I just tested: I can manually update the tag (basically by doing git tag -f latest main && git push --force origin latest). But then the GitHub "release" still says something like "created 19 days ago" even if it points at a commit which is 5 minutes old.

So here's a new idea: instead of reusing the same release, we create new releases. To ensure that we don't drown in releases, and also increase the transactional nature of things (we want to minimize the time in which CI actions in other repository fail due to "latest" not being available), we could do this as part of the "assemble-distro" workflow:

1. first delete the release named latest-new (if it exists)
2. then change the step which creates/updates the release to publish under the name latest-new (instead of latest)
3. then delete the release named latest (if it exists)
4. then rename the release named latest-new to latest

The slow part of this is step 2, but the only time when other CI workflows might run into trouble is during steps 3 and 4. Also, if there is a failure after 3 but before 4 completes, we have a (temporary) problem (but it can be fixed by manually re-running the assembler-distro workflow).

The critical question here is if step 4 actually works. Looking at the description of the API for updating a release my impression is that this is possible. But someone would have to verify this.

[fingolfin]

Actually, it does update the commit just fine! What it doesn't do is update the date of the release, which is annoying, but not really a problem...

[fingolfin]

Actually the tag also did not move to the latest commit correctly, but this at least was fixed by 2a52fe7