Typhon: Nix-based continuous integration

Thanks for expressing your concern, which seems shared with other people. I am interested in knowing what is the actual risk here? I will make the change ASAP.

I will also take the opportunity to say that at some point we want to do an overhaul of our authentication system (quote - unquote). We want to manage several users with different permissions. But we did not want to reinvent the wheel, so we want to maybe use an external authentication system (OAuth?). Any opinion on the way to go is welcome!

It is unsalted password hashed with general purpose, GPU-optimisable, hash function. This mean that rainbow table is all you need to find collision. The sole purpose of password hashes (like Argon2 and Bcrypt) is to make it expensive to compute without RAM (so it will not be feasible to compute that on GPU) and to force use of proper salt.

OAuth or similar would be good choice there.

15 Likes

Would love to see OIDC (oauth2 in disguise) support!

9 Likes

Thanks for creating this @pnmadelaine, I am very much hoping gitea gets supported at some stage.

It appears the architecture you have created might make this easier to do than other CI systems :slight_smile:

1 Like

We hope to add support for gitea as well as gitlab soon-ish. I’ve actually already started looking into the documentation for Gitea’s webhooks :slight_smile:

6 Likes

That is great news :ok_hand:t2: having a CI that can build machines and servers from my couple of gitea instances would be great.

Other approaches seem to just rely on Guthub and public repos at that.

How does this compare to Hercules CI ?

We have not tested Hercules CI. But Typhon is free software and Hercules CI is not, so for people like Lucas and I who want to deploy their own infrastructure as much as possible Hercules CI is simply not adequate.

1 Like

Don’t forget to link the actual FOSDEM talk in the first post of the thread: FOSDEM 2024 - Typhon: Nix-based continuous integration

3 Likes

Thanks, I completely forgot to share the link :sweat_smile: sadly, it appears that you can’t edit discourse posts past a certain time :frowning:

They do have a github org and documentation for their components. Which components are closed source? (I was planning on testing them and possibly your CI too).

My understanding is that the server is completely proprietary, the agent connects to it with a token that’s provided by Hercules CI. It appears that Effects are open-source though, so it could be interesting to look at them and see how they compare with Actions. Both approaches look similar, although according to the documentation effects have access to some local state, actions do not (well I guess you can do anything by using the internet, but it’s not really the spirit ^^)

4 Likes

Hello everyone! Here is a little update on what has been going on:

But most importantly we opened a Zulip instance, where you can come to ask for help and where I will probably continue posting semi-regular updates like this one.

I am not sure that I will keep this thread updated unless there is some big piece of news like a first release, as I don’t want to create spam.

Thank you everyone for the feedback, and I hope I will discuss the design of Typhon with some of you on Zulip!

9 Likes

Heya!

This project is super cool, thanks for sharing this.

Is there any way to trigger builds via a URL and fetch builds via SSH? That way it can be used with Gitolite or pure Git via a hook.

1 Like

@Marcc The webhook system in Typhon just exposes an API endpoint for each project and passes any POST request that is sent to it to a user-defined action that can in turn send commands to Typhon to create jobsets. Thus as long as you can send POST requests from your forge, you can trigger builds automatically! (in theory… atm you’ll have to do some manual work because of Evaluation is not triggered on new jobsets · Issue #3 · typhon-ci/typhon · GitHub)

You can’t currently retreive build results via SSH, but you can expose them over HTTP! Thanks to the discrete (meaning undocumented) feature that distributes store paths from the API when passthru.typhonDist = true; is set in you job’s derivation.

Out of curiosity, why zulip for chat? The nix community is heavily invested in Matrix. Maybe it would be a good idea to bridge to a Matrix channel?

Gitea and cachix support looks great and shows how we can add forgejo and attic story!

1 Like

Out of curiosity, why zulip for chat?

Zulip seemed like a good solution to have easy access to conversation logs. I personally hate Matrix for this, just scrolling up a few messages is an awful thing to do on Element. I am open to the idea of maintaining a bridge, depending on how much work and resources it requires.

Gitea and cachix support looks great and shows how we can add forgejo and attic story!

lib.gitea.mkProject can be used with forgejo, as it is still a soft fork of gitea and is completely backwards compatible (I actually test Gitea support on codeberg.org)!

3 Likes

While still compatible for now, the decision was recently made to make forgejo a hard fork. Forgejo monthly update - February 2024 — Forgejo

I have my complaints about matrix as well, but also don’t have a zulip account and don’t really want another chat service if I can avoid it. I think it’s important to go where the community is, and for better or worse it’s Matrix for the Nix community.

3 Likes

So I’ve just deployed my own typhon instance and put one of my github repository under the typhone instance as CI. However, the job always fails on evaluation. On the web interface, it just says Failure on the Nix evaluation status and I don’t really know where I should look to find out more information why the evaluation would fail. Any clue where I should take a look? By the way, the repo could be built successfully outside of typhon.

I’ve just created an issue for this feature in the typhon github repository.

1 Like