rajivr___ has quit [Quit: Connection closed for inactivity]
drakonis_ has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
jonringer has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
<c00w>
I've been thinking about spinning up a little service w/ 2 layers of raspberry pis that runs nix-review for nixpkg cl's for all cl's. Would that be useful for people?
<simpson>
c00w: Sure, but "little" sounds like it might be a problem, unless you're gonna mask out problematic packages somehow.
<samueldr>
c00w: what's the endgoal?
<samueldr>
and raspberry pi is... a loaded term :)
<samueldr>
which raspberry pi, running which arch?
<gchristensen>
what is a layer of raspberry pis?
<samueldr>
crust, filling, and what's the name of the top that's criss-crossed crust?
<gchristensen>
oh the lattice?
<c00w>
If I could run on pastries, I would have soo many more computers.
<c00w>
re: what's the endgoal - I'd like to stop having breakages happen after a merge, it would be much more preferable to find them at the PR level.
<c00w>
re: what is a layer of raspberry pis - The issue is that you can't trust the PR code, so I was going to have one RPI netboot from another one, and use a proxy to only allow downloads.
<c00w>
aka lazy security isolation
<Taneb>
c00w: most builds are for x86_64, and Raspberry Pis are all Arch, is the problem I see
<gchristensen>
what types of failures is ofborg missing?
<c00w>
gchristensen - I can't run it and it doesn't automatically run?
<c00w>
Unless I'm missing something (which I'd love since what I'm proposing is work and I'm lazy).
<c00w>
gchristensen, Sweet - What are you thinking? Whitelist me? Or would you like help on isolation to have it safely run on all PR's? Or something else?
<gchristensen>
I think it is already pretty safe
<gchristensen>
what kind of isolation are you thinking?
<gchristensen>
wait hold on
<c00w>
I assumed the reason it didn't run on every PR with full builds and tests was secuirty concerns - is that not the case?
<gchristensen>
that is it, but we can, without too much difficulty, make that less of a problem at this point.
<c00w>
Taneb: Definitely, and I could probably also do x86 easily, but they're just more expensive and I care more about aarch64.
<gchristensen>
it doesn't run nix-review though, it just does builds and evaluations
<c00w>
gchristensen: I think builds is a great first step.
<Taneb>
c00w: right
<c00w>
Once we have that it's pretty easy to incrementally add more things.
<gchristensen>
okay
<c00w>
How can I help?
<gchristensen>
we can do that for linux (aarch64, x86) without trouble
<gchristensen>
I don't think you can, just have to setup a couple more machines and flip a switch
<c00w>
Lol - ok :D
<c00w>
And it'll just do nix-review calculations and run all builds on every PR?
janneke_ has joined #nixos-dev
<gchristensen>
ofborg doesn't do nix-review. I'm not sure what nix-review does which ofborg deons't
<c00w>
(I'm just saying nix-review calculations when I really mean dependency).
<gchristensen>
I think nix-review fetches its dependency info from ofborg
<c00w>
Oh sweet - so the logic is already there.
<c00w>
I'm very much out of the loop here.
<c00w>
Are there any load issues? I know that this could be quite expensive
<gchristensen>
probably not
janneke has quit [Ping timeout: 245 seconds]
<gchristensen>
the ofborg patreon should cover it okay
<samueldr>
yeah, nix-review will re-use the dependency info from ofborg when it exists
<c00w>
Sweet - and you're okay with the security issues?
<gchristensen>
well just doing a build and evaluate is pretty good
<gchristensen>
since the builds are sandboxed nicely. some potential shadiness around networked fetchers.
<cransom>
what's it going to do, make network calls? bwahaha.
<c00w>
Well.... that's a ddos
<c00w>
and network + cpu = bitcoin miner
<gchristensen>
yeah its possible
<c00w>
But it should be fine.
<c00w>
But sounds like this is going to be fixed - thanks a bunch christensen for turning this on :D
<gchristensen>
sure
<gchristensen>
taking ownership of all the builders has been on my to-do list anyway. iterating is hard when you have builders who don't update often.
<samueldr>
if it's trivial to map a github PR author to "is a nixpkgs contributor", would it be possible to restrict non-cached fixed-output derivations to those that already contributed?
<samueldr>
and any contributor being allowed to ping ofborg into unlocking the PR from a new user, somehow
<samueldr>
that'd at least close the drive-by miner scenario
<samueldr>
mostly
<c00w>
It really reduces the usability though, unless we block merges without the fix.
<LnL>
you can query the fixed dependencies in the build tree and check the cache
<c00w>
Since new code will get eyeballed, then likely merged w/out the ofborg step since it looks like it can't break anything.
<c00w>
s/block merges without the fix/block merges with the ofborg check/
<LnL>
but a cancel operation might be better if we want to open it up for everybody
<samueldr>
yeah, thus why "any contributor" being able to vouch for that particular PR
<samueldr>
"vouch" may not be the right term
<c00w>
It also kills iteration time (since you have to wait for another human to show you what broke on aarch64 / darwin).
<gchristensen>
the vast majority of PRs do get built by ofborg
<LnL>
also building everything automatically could be problematic for the queue with things that we know will timeout upfront
<LnL>
a batch of staging prs could snoop away a significant amount of resources
<gchristensen>
true
<samueldr>
this sounds like it'd profit from the unfair scheduling thing