Alternative for ReleaseTools driven by GitHub Actions

[fingolfin]

Currently most (?) package releases are made with the help of ReleaseTools. This is fine and well but even though it tries hard to automate things, it still requires some setup and learning, and can fail due to various kinds of issues (e.g. no pdflatex installed; wrong GAP version; bad interaction with other packages; incorrect paths in the generated documentation HTML, etc.).

We could instead allow handling all this via a GitHub Action (this is how Julia packages do it): Basically, you push the commit you want to release to GitHub (as you would do now). Then you trigger a GitHub Action, pointing it at this tag (there are multiple ways how this could be implemented, but let's just say the package authors has to go to specific URL, perhaps type in the commit hash or its URL on GitHub, and press a button).

This then triggers a GitHub Action which basically runs release-gap-package for you, but in a fully defined environment: with a specific GAP version, with latex installed, etc.). If all works well, it also creates a tag on that commit with the appropriate version, uploads all files, and updates the website.

Ideally it really would use the usual ReleaseTools script (possibly after improving it a bit).

[fingolfin]

@limakzi is working on such a thing and reported about it during the recent GAP Days in St Andrews.

A prototype is already in use in his package https://github.com/limakzi/smallantimagmas and also at https://github.com/gap-packages/PatternClass/ -- see https://github.com/gap-packages/PatternClass/blob/master/.github/workflows/release.yml

The plan is turn much of this into a dedicated action at https://github.com/gap-actions/release-pkg/ -- though it may be split into multiple parts. E.g. like this:

• one action to make the actual release (create tarballs, upload them to a GitHub release)
  • instead of running a .release script this could offer an argument that can take a shell script, so that we can write the code to be executed into the action YAML file
• one action to publish the release to the package's website.

I certainly have a bunch of ideas on what and how one could do various things, and so once something is there I'd be happy to comment, give feedback, perhaps also help out.

But here my view point is: they who write the code have the strongest voice ;-). I.e. actual code is preferred over my theories and ideas ;-).