Teach `make dist-gzip` to print the tarball name as last line, and use
it as `create-archive` action.
Add a `make print-version` command which packit can use. The builtin
default only works if there is at least one git tag, which is not the
case for starter-kit (which is never released).
Travis stopped handing out free credits since their plan changes last
November, so tests have not run since then.
Cirrus CI offers an API similar to Travis, and also explicitly supports
/dev/kvm access.
Eventually we want to use the cockpit/tasks container directly. But we
can't fix the /dev/kvm permissions inside that as `sudo` does not work
in that. Once we fix that, the setup will become much cheaper and
simpler.
Travis now offers /dev/kvm, and its machines are powerful enough to run
our browser integration tests, at least for small projects.
Building an RPM on the Ubuntu host environment is a bit tricky, as there
are no installed RPMs. Thus ignore the BuildRequires, and install
appstream-util explicitly. In the future, the rpm/deb build should
happen inside the VM (like Cockpit does).
Add two scenarios for current Fedora and CentOS 8.
Switch to the "minimal" environment to make the test easier to reproduce
locally and more explicit.
Closes#386
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
