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
Nobody in the development team has ever really used that, it needs a ton
of dependencies, and doesn't work in toolbox/Silverblue. Our own
vm-run/image-customize etc. machinery is efficient enough, and proven to
work.
Closes#321
Rename some files and change some identifiers to be neutral to the
application name. This makes it simpler to change everything to a proper
name when cloning this project.
Document in the README how to find the remaining places to change.
Closes#20
