<andi->
labels for successful CI would allow filtering for PRs that look okayish and just need a human look
<gchristensen>
sounds good
<cole-h_>
the "supported platforms" check would be slightly harder, I think
<andi->
obviously the union between those and the platforms that we have hardware for
<gchristensen>
also applying a "build-failed-platform-name" label might be useful to signaling the failure without risking the sanctity of the red X
<qyliss>
ooh yes
<andi->
should those labels be specific to some CI software or would we be fine with random scripts settings them as well?
<cole-h_>
gchristensen: re: "I think we're getting macs again" -- x86_64 "and" aarch64, or "or"
<gchristensen>
my request was for intel at a minimum, arm if possible
<gchristensen>
(so, 1 or 2)
<cole-h_>
andi-: how do you mean random scripts? Like how we have GH Actions that just curl the repo?
<cole-h_>
:P
<gchristensen>
andi-: good question
<andi->
when I run my home-made CI system against all PRs
<gchristensen>
and start blasting comments everywhere? :)
<andi->
I wouldn't want that because that would reduce the meaning of the CI system. I trust ofborg a lot more than any random script running on a random nix config.
<gchristensen>
<3
<andi->
are we pinning the ofBorg nix version to the minimal supported version or just stable from stable nixpkgs?
<gchristensen>
I don't remember, it'd be good to make the evaluator (at least) use minimum
<gchristensen>
current stable's -minimum
<andi->
Yeah, and someone might at some point like to also test flake eval..
<cole-h_>
well, `nix eval .#package` currently fails on pretty much every package IIRC
<gchristensen>
let's stay focused for now :P
<cole-h_>
hehe
<andi->
yeah, ignore flakes :P
<andi->
It is a trend that goes by.
<cole-h_>
(aside: `nix eval .#hello --json` gives an outpath, but without `--json`, fetchurl's boot.nix complains)
<andi->
where does ofborg detemine that everything that was scheduled has succeeded?
<gchristensen>
we don't have a solid event for builds done too
<cole-h_>
I wonder if the bare minimum would be to add those build-failed labels, and then also filter by status:success. If any of the eval checks fail, they'll be filtered out, and if you filter out all the build-failed labels you'll get the PRs without failing builds and succeeded evals
<andi->
I guess the lack of an event when all builds finished is due to the lack of state? We only keep in memory what needs to be built shortly after the eval?
<gchristensen>
yea
<gchristensen>
but you can see what is happening when you update the statuses
<gchristensen>
could just do like, are any in flight? no? this is the last one? okay, we're done I guess
<gchristensen>
does that make sense?
<andi->
oh, that information exists? Even across ofborg restarts?
<gchristensen>
it is provided by the github status API
<andi->
Abusing githubs statuses as storage?
<gchristensen>
:)
<gchristensen>
you can enumerate the current statuses on a commit
cole-h_ is now known as cole-h
<andi->
That might work.. I am not really liking that tho.. Isn't there a celery style library for rust?
<gchristensen>
what don't you like about it?
<gchristensen>
github is the actual state we care about
<andi->
Is it? How do I query it for: Give me all the PRs where not builds are missing?
<andi->
We've already had a few situations where we did miss events and had to somehow backfill/write scripts?
<gchristensen>
well to the query-er maybe it isn't but to "looking at a PR whats up" it is
<andi->
maybe that is good enough. As long as that PHP script stays available we don't need more state..
<gchristensen>
which PHP script? :x
<andi->
That one that ingests into rabbitmq?
<gchristensen>
ah!
<gchristensen>
yeah =)
<gchristensen>
the one I won't rewrite just to spite the "I don't like PHP"ers
<andi->
Given how low-traffic that endpoint is that is probably a suitable solution into the year 2050 when we will have 200k PRs/month
<gchristensen>
yeah
<gchristensen>
opening a new connection on every event sucks a bit but I haven't run out of ephemeral tcp ports yet
<andi->
We could still talk about making it HA by having a Python/Rust/Haskell/... version of it running elsewhere. If rabbitmq would deduplicate messages that would be neat :D