cockpit/containers
Martin Pitt d4d347b616 workflows: Run unit tests in our tasks container
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 f16f1fc14b
2024-02-20 11:29:02 +01:00
..
flatpak ruff: move linter settings to [lint] section 2024-02-02 16:16:19 +01:00
ws containers/ws: Show how to append extra options to RUN label 2023-12-12 16:30:11 +01:00
Makefile.am containers: Update ws-container* make rules 2022-02-17 11:19:30 +01:00
README.md containers: Update README 2022-05-23 12:53:21 +03:00

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.