Yes, if this is the route we want to go I’d be happy to work on it. I’d probably want a couple people to talk through design with me before getting started. And one or more who would want to contribute could make this more of a team project and hopefully avoid some of the problems we have with other similar projects built by one person. 
1 Like
The ability to collect statuses from external sources would be very helpful for unfree package sets and for checks that require special hardware (e.g. GPUs)
I’m sorry, but using GitHub actions for this sounds like an extremely bad idea to me.
- This is going to cost GitHub real money, and I wouldn’t trust them to be willing to do that. How much was the Equinix sponsorship worth again? Yes, running actions on forks is allowed by GitHub TOS, and other –much smaller– projects already do this as well. But I’ll bet that as soon as our CI causes costs which exceed some threshold, GitHub will take actions against it.
- Even if GitHub works out fine for now, will it long term? With expensive sponsorships, we are one bad year for the company away from having to frantically search for an alternative again. This is the situation we are in right now, so why not search for more sustainable solutions this time?
- Just because we are already deeply locked in to the GitHub platform doesn’t mean it is okay to take some big steps further in that direction.
- What is the trust and threat modeling of running GitHub actions in forks?
I find it a bit disappointing that a project this size can’t manage to stand on its own legs in terms of infrastructure, and continues to rely on companies sponsoring stuff.
9 Likes
(post deleted by author)
See the meeting notes for today’s infra meeting where we mainly discussed the CI situation: infra/docs/meeting-notes/2024-11-14.md at 7688f20babbeb27a10e4d8669fffe4b0ed00e17f · NixOS/infra · GitHub
Here is the high-level plan:
- Infinisil wants to take a look at evaluating nixpkgs in github actions to compute the number of changed paths
- Independently we will take a look how we can build packages.
- For the beginning we will just run github actions as they are designed as a pull_request event. This is because it’s the most straight forward way and we actually have not validated if we cannot just build everything fast enough without resorting to my initial strategy.
Independently from meeting we also have other discussions about how we can develop ofborg in the future. However this might not happen before February, so we need some alternative solution in the meantime if not longer.
3 Likes
If you want to help migrate ofborg to a new sustainable infrastructure, be my guest. We can also evaluate both plans parallel, so please don’t feel blocked by us. If you want to help, you can join #infra:nixos.org matrix channel.
The infra team is currently small and therefore has to focus on the essential that is the core building infrastructure but if we have more helping hands we can also expand to bigger things. As of now public holidays for many of us are approaching, which we also want to enjoy.
12 Likes
This thread is being somewhat duplicated on GitHub, so please check my comment there:
I haven’t seen my concerns on sustainability and trust addressed, and couldn’t find anything in the discussion notes or on the GitHub issue either.
1 Like
Personally I only read about your post after the meeting…
To address your points. I think github actions are actually more secure than ofborg because they run builds in isolated VMs. Also we had to learn our lessons with insecure usage of GITHUB_TOKEN. Also note that we decided not to build in forks (also from a security standpoint this should not make a difference), because we think it should be possible to run everything from the NixOS org.
I don’t think development of ofborg is currently sustainable. It doesn’t receive a lot of contributions because it’s quite hard to get a development setup for testing the stack locally. This is probably fixable but not in the current timeframe.
Infinisil made also some good progress on optimizing evaluation (based on amjoseph’s work). Those could be in future retro-fitted into ofborg. The resulting tooling can than be also run from a local nixpkgs checkout, which actually makes switching to a different CI easier than ofborgs hard-coded github integration.
From my past experience in nix-community, Github also does not simply turn off resources for legitimate projects. They usually give a heads to fix resource issues.
7 Likes