NotAShelf/circus
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: highlight Hydra's core issues

Browse source 
Obviously not all of them, but things to avoid locally.

Signed-off-by: NotAShelf <raf@notashelf.dev>
Change-Id: If9a7695f9633aef95d2513cad5de83e86a6a6964
This commit is contained in:
raf 2025-11-02 23:20:48 +03:00
commit fc19dd27c4
Signed by: NotAShelf
GPG key ID: 29D95B64378DB4BF
1 changed files with 23 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/DESIGN.md
View file

@ -37,3 +37,26 @@ FC commits to this design with minimal tweaks. Most critically, FC is not
designed to be used alongside Nixpkgs. Sure you can do it, but that is not the designed to be used alongside Nixpkgs. Sure you can do it, but that is not the
main goal. The main goal is a distributed, declarative CI that has learned from main goal. The main goal is a distributed, declarative CI that has learned from
Hydra's mistakes. Hydra's mistakes.
### Component Interactions and Data Flow
Hydra follows a tightly-coupled architecture with three main daemons:
```ascii
Git Repository -> Evaluator -> Database -> Queue Runner -> Build Hosts -> Results -> Database -> Web UI
```
In this flow, the responsible components are as follows:
1. **hydra-server** (Perl, Catalyst): Web interface and REST API
2. **hydra-evaluator**: Polls Git repos, evaluates Nix expressions, creates
`.drv` files
3. **hydra-queue-runner**: Dispatches builds to available builders via SSH/Nix
remote
4. **Database (PostgreSQL)**: Central state management for all components
While simple on paper, this design leads to several issues. Besides the single
point of failure (the database), the tight coupling leads to requiring shared
database state and contributes to the lack of horizontal scaling in Hydra. Also
worth nothing that the evaluator must complete before the queue runner can
dispatch, the dependencies are synchronous.