| 26 Dec 2025 |
|  jasper @ 39c3 ☎️ 62749 changed their display name from jappie to jappie @ 39c3. | 15:49:41 |
| 27 Dec 2025 |
| jasper @ 39c3 ☎️ 62749 changed their display name from jappie @ 39c3 to jasper @ 39c3 ☎️ 62749. | 13:30:50 |
|  Nyte changed their display name from realnyte to Nyte. | 21:19:58 |
| 28 Dec 2025 |
 eveeifyeve | Good question for the hydra team, can hydra yet be used in github/gittea yet? If not what can I do to help? | 15:48:56 |
 K900 | What does that even mean | 15:51:54 |
| K900 | Hydra can run on arbitrary git repos | 15:52:13 |
| K900 | It's pull based | 15:52:13 |
| eveeifyeve | So like when you do a pr it runs? | 15:54:56 |
| eveeifyeve | * So like when you do a pr it runs? That's what I mean. | 15:55:09 |
| K900 | Hydra is not designed for that | 15:55:24 |
| K900 | And you probably don't actually want Hydra | 15:55:30 |
| K900 | Just run nix build in github actions | 15:55:39 |
| K900 | Hydra is really designed to be post-merge and nixpkgs sized | 15:55:58 |
| K900 | Your use case is neither | 15:56:05 |
|  @ungeskriptet:matrix.org left the room. | 16:01:22 |
| eveeifyeve | So you use build-bot/github actions for that right? | 16:02:13 |
| eveeifyeve | * So you use build-bot/github actions for that right? Because I am not sure to use build-bot along with hydra. | 16:02:31 |
| K900 | I'm not sure who "you" is but generally that's probably what you want yes | 16:02:42 |
| eveeifyeve | * So you use buildbot/github actions for that right? Because I am not sure to use buildbot along with hydra. | 16:02:36 |
 tomberek | eveeifyeve: There is a Hydra plugin to make a jobset per PR from Github webhooks. It does work and it is possible to connect it to GHA status reports, but it has pretty minimal usage, poorly documented, and might run into bugs. (i've used it at a small scale)
Another option would be to submit jobs directly using the Hydra API per GitHub Action. Also, this use-case isn't thoroughly developed either.
I do think some kind of easy Hydra / Generic-Forge integration would be nice to have. I see a bunch of places essentially re-inventing this all the time.
| 18:49:20 |
| eveeifyeve | I might be better off making my own CI. | 18:50:33 |
| eveeifyeve | * I might be better off making my own CI cause buildbot is just not the best to use. | 18:51:00 |
| tomberek | I'm trying to see if there is interest for there to be a better set of tools for making CI systems. Rather than building a full CI/CD system, Nix could mature the tooling needed so that anyone can build their own. Some examples of the sorts of things this could mean:
- official nix-eval-jobs
- nix-eval-jobs with better perf/caching
- eval/fetcher/tarball cache distribution niceties
- remote builders can submit jobs to a job queue
- smart job distribution taking into account local closures
- Hydra + nix-daemon: why are these two separate things? The event loop is different, but what if all builds on a Nix system exposed a web and API interface and ability for a pull-based workflow (Hydra) OR an on-demand one (nix-daemon).
| 18:56:09 |
|  embr joined the room. | 19:42:26 |
| eveeifyeve | This might be best for when we do eventually do a rewrite nix in rust. Cause in the couples of meetings ago, we did eventually want to look into a full rewrite so playing around with harmonia for now seems the best option before going ahead and doing a pr that fully rewrites nix. | 20:27:20 |
| embr | I might be interested in this, but have to think about it after 39c3 - I just finished my work on Gorgon, and I've got a lot of thoughts in this kind of direction. | 20:33:33 |
| tomberek | https://nlnet.nl/project/GorgonCI/ | 20:50:18 |
 vcunat | When a complex software has been used in production for many years, it almost always takes really lots of effort to rewrite it and get a similar quality. | 20:52:45 |
 7c6f434c | Hopefully an evaluator rewrite will tell the caching layer what files have been looked at at all. Hopefully a daemon rewrite would have client-reference-counting for builds from the beginning… So quality is probably not something that can be compared in a linear order | 20:55:38 |
 Sergei Zimmerman (xokdvium) | In reply to @7c6f434c:nitro.chat
Hopefully an evaluator rewrite will tell the caching layer what files have been looked at at all. Hopefully a daemon rewrite would have client-reference-counting for builds from the beginning… So quality is probably not something that can be compared in a linear order There’s no reason to rewrite the evaluator to do this now. It already funnels everything through an internal I/O abstraction | 20:57:15 |
