Daemon and client
The Testground runtime revolves around a traditional daemon/client architecture, communicating over HTTP.
This architecture is flexible enough to run the daemon within a shared cluster, with many users, developers, and integrations (e.g. GitHub Actions) hitting the same daemon to schedule build and run jobs.
At the moment, we do not run Testground in shared-cluster deployments; most developers spin up personal Kubernetes clusters, and run both the daemon and the client on their own development machines, pointing the local daemon to the remote k8s API.
However, as of Testground v0.5, we do support running the daemon within a Kubernetes cluster as a pod. This capability is vital to pave the way for shared-cluster deployments, which will enable much more efficient resource utilization and CI workflows.
Testground Daemon
The Testground daemon is responsible for:
Scheduling and executing tasks (plan builds and test runs).
Collecting the outputs from test runs into an archive.
Performing builder and runner healthchecks.
Setting up the dependencies for builders and runners to operate.
You start the Testground daemon by running:
Exit with Control-C
.
Testground Client
The Testground client offers a CLI-based user experience, allowing you to:
Manage and describe the test plan and SDK sources the client knows about.
Interact with the daemon by executing builds and runs, collecting outputs, requesting runner termination, and triggering healthchecks.
Asynchronous Tasks
The Testground daemon executes tasks, i.e., plan builds and test runs, asynchronously. By default, when you execute a build or run command, you'll be returned a task ID. This ID can be used to check the status of the task:
Or see the task logs - you can use -f
to follow the logs live:
To visualize all the running tasks:
You can also wait for the task completion when building or running by appending the flag --wait
. This way, you will not only wait for the completion of the task, but also receive all the logs live:
Last updated