d4d347b616
This reduces our tools like `ruff` to a single source of truth (as all
our other projects already run their unit tests and linting in the tasks
container). It also removes a lot of moving parts only relevant for CI.
In practice, us developers run the unit tests in toolbox or our own dev
machines anyway.
Move building the guide in the release workflow to the tasks container
as well.
Cherry-picked from main commit
|
||
---|---|---|
.. | ||
flatpak | ||
ws | ||
Makefile.am | ||
README.md |
README.md
Cockpit Containers
- ws: Cockpit's web server, for installation on CoreOS; uses SSH to connect to the local host or remote machines
- bastion: A reduced variant of the web server that runs unprivileged, and can only connect to remote machines. Suitable for deploying on e.g. Kubernetes. This is currently a prototype.
- unit-tests: Our project's unit tests run in this container; usually on GitHub PRs, but you can also run it locally for reproducing failures.
- flatpak: Scripts for locally building, running, and testing our Cockpit Client flatpak.
See the individual README.md files in the subdirectories for details.
ws container development
Build the container:
$ make ws-container
Run the built container and log in interactively as a shell:
$ make ws-container-shell
When running docker the 'sudo' command will be used to get necessary privileges.