GitHub's base VMs don't automatically refresh package indexes, so it can
happen that one of the package dependencies get out of date and are not
available on the mirrors any more.
Run `apt update` first to ensure that the workflow installs the latest
packages.
With [1] the release container moved from dockerhub to GitHub's
container registry, as we both build and use it from GitHub. This avoids
running into docker.io pull limits.
[1] https://github.com/cockpit-project/cockpituous/pull/353Closes#398
This avoids a lot of moving parts in our infrastructure (webhook,
npm-trigger roundtrip, tasks container), works in exactly the same way
for independent third-party projects, and does not need *any* secret
other than the automatically provided GitHub token.
Let this run early every morning, roughly similar frequency as
cockpituous used to do. Also add a manual trigger, so that we get a
button to run it on demand.
Closes#384
Enter the new world of GitHub actions [1]/GitLab pipelines [2]. This
simplifies our end of the infrastructure considerably:
* No need any more to set up webhooks, all the relevant configuration
is right in the workflow file.
* Does not need any infrastructure on our side any more, and thus works
for third-party projects. They just need to set up their own secrets.
* GitHub automatically provides a temporary `GITHUB_TOKEN` with
sufficient write access to the project to publish a release, so we
don't need to carry around that secret. Thus if your project only
releases to GitHub, there is zero secrets management.
Also adjust cockpituous-release a bit (update Fedora version, fix
project name copy-pasta), point to the action workflow and necessary
secrets.
Closes#380
