KernelCI Dashboard

Our Web Dashboard to evaluate test results from the common results database(KCIDB). Available at dashboard.kernelci.org.

The new KernelCI Web Dashboard is a web application created to provide access to static checks, build logs, boot logs and test results related for the Linux kernel CI/test ecosystem. All that data will be provided by KCIDB system from the KernelCI Foundation.

Repository

What we have as a repository is a monorepo containing the dashboard (the web application) and a backend.

Dashboard

A web app built with React + Typescript, to see more information check the dashboard README.

Backend

A Python http server built with Django + DRF, to see more information check the backend README.

Quick run

If you want to just run the project, you can try out pre-built images with the docker-compose-next.yml file. This pulls images from GHCR and runs them locally without needing to rebuild them. You may still need to set up environment variables, so read the docs.

Build

Frontend

Create a .env file in /dashboard, check and set the variables and their values

 cp ./dashboard/.env.example ./dashboard/.env

With docker, you can start just the frontend with docker compose up --build proxy. It is also possible to run the dashboard outside of it for development purposes.

We use pnpm to help with the package management. Install the dependencies with

pnpm install

Then start the dev server with

pnpm dev

If you want to test the production state of the dashboard, use

pnpm build
pnpm preview

Backend

Create a .env file in the base directory,

 cp .env.backend.example .env.backend

Create a secret key for Django:

export DJANGO_SECRET_KEY=$(openssl rand -base64 22)

We are not using sessions or anything like that right now, so changing the secret key won't be a big deal.

Since the production database is not open for the public, we use ssh tunneling with a whitelist to access it. This means that the docker setup currently can't access it, but we have a local database that is connected automatically if you don't change the env vars.

If you do use docker, you should create a secret file with the database password:

mkdir -p backend/runtime/secrets
echo <password> > backend/runtime/secrets/postgres_password_secret

If you are going to use a database user other than kernelci, set it to DB_USER:

export DB_USER=<user>

If you are setting up instance different than production KernelCI dashboard, you need to define CORS_ALLOWED_ORIGINS. On .env.backend:

CORS_ALLOWED_ORIGINS=["https://d.kernelci.org","https://dashboard.kernelci.org"]

It is also possible to run the backend outside of docker for development purposes. Simply run the ssh tunnel with the instructions sent to you by the database manager, then export the variables seen in .env.backend.example.

For other optional envs, check the backend README.

Common

Startup the services:

docker compose up --build -d

Docker exposes port 80 (that you don't need to enter in the URL) instead of 5173 and 8000 that is used when running the dashboard project outside of docker. So you can hit the frontend with http://localhost and the backend with http://localhost/api when running locally.

Make sure that docker has the right permissions and has access to the environment variables. One way to do that is to set up a docker permission group.

If you are running the commands for exporting the environment variables and running docker separately, you can run docker with admin privileges and allowing environment variables with:

sudo -E docker compose up --build -d

Or you can also run the env exports and docker compose within the root user by running sudo su.

Tip: you can create a quick script to set all the necessary envs and start the services. This will also allow docker to see the environment variables correclty. Example:

export DB_USER=email@email.com
export DJANGO_SECRET_KEY=$(openssl rand -base64 22)
export DB_NAME=kcidb
export DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/..."

docker compose up --build

[Note] If you are going to run using only the local database, the DB_NAME should be dashboard and the DB_USER and DB_PASSWORD should be admin (for now). This simply follows what is going to be setup by the dashboard_db service on docker compose.

Deploying to production

To deploy to prod you need to push a tag in the release/YYYYMMDD.N format like: release/20240910.0

Publishing container images to GHCR

The workflow .github/workflows/deploy-containers.yaml publishes Docker images for the three services used by the dashboard stack:

• dashboard-backend (from ./backend)
• dashboard-frontend (from ./dashboard/Dockerfile)
• dashboard-proxy (from ./proxy)

This workflow is triggered on pushes to main (on the original repository) and also manually (workflow_dispatch) and pushes images to GHCR under ghcr.io/<owner>/<repo> with two tags for each image:

• latest
• ${{ github.sha }}

At the end of the run, the workflow writes an image digest summary in the GitHub Actions job summary.

Test results email reports

See details about our new notifications system.

Contributing

Check out our CONTRIBUTING.md, and there is an onboarding guide to help get acquainted with the project. Contributions are welcome!