<qyliss>
unexplained hash change pushed straight to master
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]
supersandro2000 has joined #nixos-security
<andi->
The original version never worked and ofborg actually reported the mismatch :(
<gchristensen>
doesn't nix-build exit differently if a hash mismatch was detected?
<gchristensen>
that is the kind of confident failure we could throw up red X's for
<andi->
I know we discussed that before but why aren't all build failures red crosses?
<andi->
Apparently people ignore the grey ones anyway and maybe if it were red they'd at least check them and comment that they are unrelated / flaky / whatever ?
<qyliss>
because if red crosses were frequent occurrences, people would stop checking them
<qyliss>
imagine if every time Darwin builds were broken they were red crosses
<andi->
So? Are those flaky? False-negative?
<andi->
If darwin is one of the supported platform and it doesn't build there...
<andi->
either fix or remove the platform (or merge anyway if flaky)
<andi->
better than ignoring failures
<qyliss>
my point is that Darwin builds are regularly just broken because OfBorg or the servers are broken
<qyliss>
they were broken for the last few months
<andi->
Then that needs higher priority fixing? What can we do to help with that?
<andi->
Either we support darwin or we just drop it...
<qyliss>
it's fixed now
<qyliss>
but there will always be issues that we can't fix immediately, and it's important that while they're being fixed, people don't start building up alert fatigue
<andi->
Right now Ci failure doesn't prevent merges as you might not realize in the huge list of (green!) checks that there is one or two grey ones.
<andi->
So we could just skip building packages entirely.
<qyliss>
GitHub won't collapse the failures if there are non-green ones
<qyliss>
so it's pretty easy to distinguish
<qyliss>
if it's showing you the list of checks next to the merge button, that means something isn't green
<qyliss>
it also shows you that little pie chart thing
<andi->
mhm, I only checked the merged PR that was related to what you linked above and I had to scroll up on the list after expanding it.
<gchristensen>
there are just too many reasons a build is going to be red X'd, and a red ofborg X should NEVER be ignored
<qyliss>
andi-: it changes once the PR is closed
<qyliss>
that's not representative of what it looks like for an open PR
<gchristensen>
training users to ignore red X's "sometimes" is dangerous
<qyliss>
^^
<qyliss>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 470
<andi->
So we never fail things?
<andi->
Also not great..
<qyliss>
we fail things when we're _sure_ there's a failure
<qyliss>
(or when the base branch doesn't evaluate, which is a bit of a problem for eval fixes...)
<andi->
How do you reliably do that with arbitrary builds?
<qyliss>
by erring or the side of caution and not marking them as failures when we're not sure
<gchristensen>
exactly, we don't fail builds
<gchristensen>
except we can here, fixed output builds should always pass
<andi->
So we just apply thoughts and prayers?
<gchristensen>
okay see ya, let me know if you want to have a real discussion
<andi->
I am serious about it. I think we overstate fatigue..
gchristensen has left #nixos-security ["WeeChat 2.9"]
<andi->
Great way of community leadership.
<qyliss>
"So we just apply thoughts and prayers?" is not a productive comment
<andi->
Well we hope for the best that everyone checks they grey errors?
<qyliss>
correct
<qyliss>
because that's the least bad option
<qyliss>
we can only depend on people to check the red crosses because they're almost always indicative of a real problem
<qyliss>
if we made everything that's currently grey red, after a short transition period people would check the red errors just as much as they check the grey ones now
<gchristensen>
the Nix deployed to the builders isn't running unstable
<gchristensen>
https://github.com/NixOS/ofborg/pull/560 makes hash mismatch failures real failures (I was looking in to making this a real failure for about 30-45min now)
<andi->
Ok, I was about to ask if that would be acceptable.;
<gchristensen>
for sure, any failure which is never plausibly for an okay reason should be a red X
<qyliss>
gchristensen: are you looking into the target branch eval thing, btw? I think that's important to get fixed, since it's an actual false positive alert.
<gchristensen>
I took a brief look but I haven't really looked
<gchristensen>
it isn't so complicated
<gchristensen>
but more complicated than "can do it while my inlaws are here"
<qyliss>
legit :)
<qyliss>
should be a pretty rare ocurrence, at least
<gchristensen>
let's go to -borg for it
<qyliss>
not sure there's anything more to say about it :)
gchristensen has quit [Ping timeout: 258 seconds]
gchristensen has joined #nixos-security
<gchristensen>
qyliss: could you send a PR breaking the hash of, I dunno, hello or something, or a patch for something?
<gchristensen>
or andi-
<gchristensen>
ehh I can :P
<andi->
gchristensen: I was actually just hacking an one-off-builder command into ofborg to test your PR locally. Gonna continue once I'm out of the meeting.
<gchristensen>
cool
<gchristensen>
meeting? :o
<andi->
Family :D
cole-h has joined #nixos-security
zgrep has quit [Ping timeout: 250 seconds]
zgrep has joined #nixos-security
cole-h has quit [Ping timeout: 246 seconds]
star_cloud has quit [Ping timeout: 252 seconds]
star_cloud has joined #nixos-security
rajivr has quit [Quit: Connection closed for inactivity]
star_cloud has quit [Ping timeout: 240 seconds]
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-security
star_cloud has joined #nixos-security
cole-h has joined #nixos-security
supersandro2000 has quit [Killed (karatkievich.freenode.net (Nickname regained by services))]