Hello everyone! I am glad to present to you Typhon, in collaboration with my colleague Lucas Franceschino.
Short version: Typhon is a prototype for Nix-based continuous integration, iterating over the concepts of Hydra and introducing actions to replace plugins. It is fully declarative, comes with a webapp and is entirely written in Rust. We just announced it at FOSDEM, and we are looking for feedback.
When deploying a Hydra instance at work, we got really frustrated. We found Hydra hard to set up and the plugin system tedious. Our main concerns were the fact that plugins are configured at the system level, they are hard to tweak and the deployment capabilities of
runCommand are underwhelming. In the end, we dropped Hydra entirely from our CI’s workflow.
Disappointed with our experience with Hydra, and after long discussions, we decided to start writing our own Hydra!
The main idea of Typhon is to externalize the plugin system entirely, to make it as extensible and customizable as possible. Typhon keeps the core concepts of Hydra and introduces actions. Actions are user-defined Nix derivations used to communicate with the forge or do deployment.
More precisely, actions are scripts executed in isolation of the system but with access to internet and to the Nix store. They are triggered by Typhon on different occasions. At the beginning and end of every job, there is an action run that will, for instance, set statuses on your repository (or deploy something, post a message on Slack, anything!). There is also an action used to update the jobsets of a project in the best way suited for your workflow (for example fetching the PR list using the GitHub API, or just the branches, etc.), and one to receive webhooks and trigger CI automatically. Finally, a project declaration can contain encrypted secrets for the actions (like access tokens or ssh keys).
Thanks to the actions, the server is forge-agnostic, it does not know about GitHub, GitLab, or anything else. It is the action’s job to plug Typhon to a specific forge. You can write actions suited for your workflow, and to help you do this, you can use Typhon’s library. It is quite frugal at the moment, but I hope it will convince you of the potential of actions. Another benefit of actions is that you can build them locally and test them on your computer.
In Typhon, project configuration is entirely declarative: a project declaration is a Nix expression that builds your actions, sets some metadata about your project and exposes your encrypted secrets. Typhon supports both flakes and the classical workflow, as long as your expressions evaluate purely.
Finally, Typhon comes with a webapp. It enables some nice features like live logs for your jobs.
Typhon is written in Rust (both the backend and the frontend), source code isavailable at GitHub - typhon-ci/typhon: Nix-based continuous integration. It is licensed under AGPL.
For more information, please visit the documentation. It is a short read and after a general introduction it contains instructions to install Typhon and a tutorial to configure a GitHub project. You can also take a look at the Typhon declaration for Typhon itself, which is deployed on the instance https://etna.typhon-ci.org/.
As I said, the action’s library is quite frugal at the moment, there is no pre-configured deployment actions available. Only generic builders and the GitHub’s wrapper. The reason is that we are not yet sure about the best way to design the library. Should actions be configured like NixOS modules? Or is that a bad idea? Why? We are very much looking for your input on how this should be done!
Please keep in mind that Typhon is a prototype: a lot of features are not yet implemented, the interface is not ideal, and expect to find a lot of bugs. But we consider it ready for a beta, so please try it out and send us feedback! I’m available here, on Matrix or by mail (email@example.com) if you have trouble setting it up. Also, don’t hesitate to open issues with feature requests or bug reports.