RiverRoot

RiverRoot is a continuous integration server small enough to read in one sitting. I wrote it to understand what happens between a push and a green check.

You describe the steps in pipeline.yaml. Triggering a build, from the dashboard or with POST /builds, runs each step as a host process or inside a Docker container and saves the result with its output in SQLite.

• Steps run in order; consecutive steps marked parallel run together as one batch.
• A step with an image runs in a Docker container through the Go SDK, with the repository mounted at /workspace. Other steps run through bash on the host. Every step gets a five-minute timeout.
• The build stops at the first failure, and a step that could not start is recorded separately from one that ran and failed.
• Builds and their steps are saved in SQLite, one transaction per build.
• A REST API (GET /builds, GET /builds/{id}, POST /builds) and a dashboard embedded in the same binary. Demo mode seeds example builds and turns off POST /builds.
• Built and tested, but not yet started by the server: a Git poller that detects new commits and changed files, and a per-build log store that can follow output as it is written.

Checked on 24 Sep 2026 with Go 1.27 on macOS: go vet reports no problems, and 34 of 36 tests pass across the API, Git, pipeline, runner and store packages.

The two failing runner tests compare working directories. The command prints the temporary directory as /var/… and the test expects the resolved /private/var/…, which is the same folder through a macOS symlink. The tests need fixing, not the runner.

• Builds start by hand, and POST /builds runs the whole pipeline before it responds. Output appears once the build finishes, not line by line.
• The API and dashboard have no authentication, so it is for local use only.
• The public demo is a static page with seeded data; the server itself is not hosted.