<Mic92>
Right now we don't have a macos builder in our ci for quite a while. That's why we want to use github actions. Domen offered to add a cachix key into github, which we can use to build & cache packages.
<Mic92>
Also the macos builder was restricted to trusted users, which github action would not be.
<Mic92>
And for security it is probably the best to keep hydra seperate from pull requests.
<gchristensen>
maybe we could buy a mac, or find budget for a rented one, or convert a hydra one to ofborg for the time being.
<gchristensen>
(or move away from ofborg to github actions)
<Mic92>
That is an alternative
<Mic92>
But I really would keep ofborg / github actions seperate from hydra. There could be always security vulnerabilities in the builder, which should be kept away from the build building the official binary cache.
<Mic92>
gchristensen: but would this allow also contributors to build packages?
<gchristensen>
not really, macos has poor isolation. maybe it could work if macos was used as a remote builder, instead of running ofborg directly on a mac
<gchristensen>
then, at least, no secrets would be in the mac
<gchristensen>
this could work with a virtualised macos -- like how hydra.n.o runs them (and how I ran my mac before)
<domenkozar[m]>
why not use microsofts free infra in that case? :)
<niksnut>
speaking of which, are we likely to run into CPU limits or whatever?
<domenkozar[m]>
nope
<niksnut>
there are no limits?
<niksnut>
so say a chromium build won't get killed?
<domenkozar[m]>
not for OSS
<niksnut>
oh great
<domenkozar[m]>
oh per build?
<domenkozar[m]>
per build it's 12h IIRC
<gchristensen>
whoa
<Mic92>
well. this limit is higher than ofborg's 60min limit
<gchristensen>
can we create _a lot_ of builds? :) (like, hundreds of thousands a day ...)
<niksnut>
then we should just move the entire nixpkgs channel build to github
<niksnut>
provided we can manage the cache.nixos.org signing key securely
<Mic92>
Maybe we should ask github about that first
<domenkozar[m]>
Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.
<domenkozar[m]>
Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.
<domenkozar[m]>
I mean not using this infra and building it ourselves is quite irrational :D
<Mic92>
To manage the signing key security I would create a repo seperate from nixpkgs
<domenkozar[m]>
gchristensen: we probably could, but there's also concurrency limits
<domenkozar[m]>
to you're limited by concurrency + workflow limit
<domenkozar[m]>
20 concurrent jobs + 72h workflow limit
<domenkozar[m]>
which is quite a lot :D
<Mic92>
yes.
<domenkozar[m]>
(macos has 5 concurrent jobs)
<gchristensen>
please don't move actual builds to github actions :o
<niksnut>
'You can run an unlimited number of jobs'
<niksnut>
I wonder what would happen if we actually create a workflow with 80K jobs...
<domenkozar[m]>
probably nothing
<domenkozar[m]>
they'd weight we're a very popular repo
<domenkozar[m]>
they run on their own infra, it's basically free for them
<niksnut>
can jobs be dynamically populated or do they have to be statically defined in .github/workflows?
<niksnut>
it would be annoying to have to define a job for every attribute in pkgs
<gchristensen>
oh no
<gchristensen>
this can't be real, lol
<domenkozar[m]>
you probably could generate the yml file
<domenkozar[m]>
and trigger another build
<domenkozar[m]>
so eval would get attributes
<domenkozar[m]>
and then push a commit that would generate jobs to build each one
<domenkozar[m]>
you might need some way to check for dependencies though
<domenkozar[m]>
I'd start with a simple job though