<naon>
"nix-build release.nix -A R2009.ghc8102.linux.native" should run without errors right?
<michaelpj>
naon: there are some known test failures in there that aren't tracked properly. I'm trying to improve that at the moment but I'm having trouble getting it past the hydra evaluator :D https://github.com/input-output-hk/haskell.nix/pull/976
<naon>
michaelpj: thanks, mind sharing the hydra link? the github readme only links to a buildkite login-dialog
<michaelpj>
naon: you can get to it from the statuses on the commits. It's not interesting, its' just running out of memory :(
<michaelpj>
the haskell.nix eval is.... big
<michaelpj>
hopefully we might make another try at using hercules for this which is a bit saner about evaluations
<naon>
michaelpj: hmm alright, means i'll wait with adding xmonad as a testcase? Adding it without being sure if everything passes doesn't seem right (i tried it with multiple ghc versions in the past few days)
<michaelpj>
you can just open the testcase and look at hydra
<michaelpj>
it's not ideal, certainly
<michaelpj>
hopefully better soon, up to you if you want to wait
<naon>
michaelpj: which brings me back to the question: on which hydra server does the ci run? by chance you got a link? :)
<michaelpj>
although we're having trouble with it because the haskell.nix eval is so big, and it keeps failing and/or crowding out other things. So we might move it somewhere else at some point
<naon>
i see, i'd like to migrate from my private hydra instance too - however so far i couldn't find any decent open-source alternative :/
<naon>
but it's been a while since i checked
<michaelpj>
naon: did you try hercules? we did for a bit, but weren't really able to give it enough attention to really tell if it was going to be viable
<michaelpj>
I want someone to sell me a slick hercules+cachix+nixbuild.net combo...
<naon>
michaelpj: no i didn't but i just had a look at it again and i might? i was recently playing with some servant-client lib wrapping hydra - might aswell reevaluate hercules-ci before getting serious!
<naon>
michaelpj: i think roberth or domen might be interested in selling you that? :P
<domenkozar[m]>
michaelpj: what does nixbuild.net offer that hercules+cachix don't?
<domenkozar[m]>
the best way to ensure that will happen is to subscribe early and steer our products :)
<domenkozar[m]>
with resources that IOHK has that would speed things up by an order of magnitude
<domenkozar[m]>
no hard feelings if you use other tooling, but if you'd like for Nix tooling to get better then invest into it :)
<michaelpj>
domenkozar: nixbuild.net has the builders! for hercules I have to provide my own infra
<michaelpj>
I mean, I'm hoping we'll end up paying for hercules more this time around
<michaelpj>
I don't know if we pay for cachix
<domenkozar[m]>
hercules is for those that want their own builders, github actions solves that problem
<domenkozar[m]>
iirc github actions will get configurable machine sizes in a couple of months
<michaelpj>
but as, say an OSS project maintainer, if I want nix-based CI, I really need the orchestration stuff, the caching, and builders, and at the moment I have to source all of those separately. I just think there would be demand for a bundled version!
<michaelpj>
I don't think github actions is comparable to hercules
<michaelpj>
hercules has way better feedback on what's going on with your builds
<domenkozar[m]>
oh yeah for sure
<michaelpj>
and GH actions doesn't scale if you are building a lot of stuff
<michaelpj>
so okay, for a small OSS project probably that's good enough
<domenkozar[m]>
hmm not sure what you mean, once they have configurable sizes you can scale without limits?
<domenkozar[m]>
well at some point you have to pay for that probably
<michaelpj>
yeah I meant price-wise
<michaelpj>
but to be fair I haven't evaluated this in detail
<michaelpj>
I would just expect that a service deliberately built to provide nix remote-builders would do a better job of it than shoving things into GH actions
<domenkozar[m]>
almost all hosted solutions will get super expensive with size
<michaelpj>
I guess you can wire up the GH action build to use your nixbuild.net remote builders
<domenkozar[m]>
that's probably the most expensive since you're paying twice
<michaelpj>
yeah, ideally you don't want the GH action to block waiting for all the builds to finish and doing nothing itself
<domenkozar[m]>
I think for IOHK use case herucles is best bet with improvements on making agents easy to host
<michaelpj>
maybe the market of people who don't want to use GH actions but who would still want a bundle of hosted services (rather than self-hosting) not actually that big
<domenkozar[m]>
yeah that puts it into enterprise budget :)
<domenkozar[m]>
michaelpj: hercules would pay off once you'd turn off hydra, otherwise it just gets into a way by maintaining two CIs
<michaelpj>
domenkozar: well, it would give us two advantages: 1) better feedback on evaluation errors and build progress (haskell.nix has a *lot* of IFD), 2) haskell.nix evals don't kill the hydra evaluator. But yeah, we'd have to not build haskell.nix on our hydra
<domenkozar[m]>
yeah so no benefit until it's replaced
<michaelpj>
sure
<__monty__>
All or nothing is hard to swallow though.
<michaelpj>
only for haskell.nix. All our other stuff can build on hydra still. Of course, it depends on haskell.nix.... but not on the full insane haskell.nix CI build matrix, which helps a lot
<domenkozar[m]>
switching CIs is always scary
<domenkozar[m]>
but using 3 is even scarier imo
<__monty__>
Making incremental switching possible/easy would be a killer feature for hercules.
<domenkozar[m]>
maybe it's just me since I've spent a lot of time on this but hydra building all PRs is scary
<domenkozar[m]>
__monty__: as in having hosted runners?
<naon>
domenkozar[m]: slightly off topic: does hercules have openid support?
<domenkozar[m]>
it only supports github at the moment
<domenkozar[m]>
cachix supports email or github
<naon>
hmm alright thanks, means i could chain neither to my keycloak instance?
<domenkozar[m]>
not without paying for that work
<naon>
alright thanks, running this on a private server without funding i don't see that happening :/
<__monty__>
domenkozar[m]: I don't know what it would entail tbh. But I imagine someone's using hydra, and they could enable hercules and have both "just work" and then/or have a way to slowly chop up hydra's jobsets so parts of them are delegated to hercules. This way they could focus on the painpoints with hydra first and gain confidence hercules supports all their needs.
<domenkozar[m]>
__monty__: I mean that's already possible
<domenkozar[m]>
you can selectively enable repositories on both
<domenkozar[m]>
naon: yeah sorry :/ but can't afford to build custom features for 40 EUR :)
<michaelpj>
I think setting them up to share a binary cache is not so easy? at least, I can't think why else we have both our hydra cache and a cachix cache we used when we were trying hercules
<domenkozar[m]>
you can use S3 with hercules
<domenkozar[m]>
or migrate it all to cachix and use that
<domenkozar[m]>
although S3 is quite problematic since it's a lot slower for querying missing bits
<domenkozar[m]>
cachix has bulk queries for that
<__monty__>
domenkozar[m]: I had finer granularity in mind. Rather than having to switch the entirety of haskell.nix over you could have hercules deal with the worst IFD bits only or something.
<michaelpj>
eh, that sounds like a lot of effort for marginal gain
<michaelpj>
the most useful level of granularity (at an organization level, anyway) is the project/repository
<michaelpj>
which already work
<michaelpj>
s
<naon>
domenkozar[m]: fully understandable!
acarrico has joined #haskell.nix
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 260 seconds]
naon has quit [Quit: Lost terminal]
hekkaidekapus} has joined #haskell.nix
hekkaidekapus{ has quit [Ping timeout: 240 seconds]
terrorjack has quit [Ping timeout: 268 seconds]
terrorjack has joined #haskell.nix
__monty__ has quit [Quit: leaving]
fendor_ has quit [Remote host closed the connection]