buildbot-nix: CI for anything not Hydra-shaped #19
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I think it'd be great to setup CI for side-projects, e.g. this infra, etc., etc. which integrates in the code review tool.
Probably, a similar setup to Lix one with buildbot-nix wired up to Gerrit but generalized with lix-project/buildbot-nix#8.
What should be the set of workers, though?
buildbot-nix: CI for side projectsto buildbot-nix: CI for anything not Hydra-shapedRelated to #3.
Requirements:
Start from lix-project/buildbot-nix#8 and develop the rest ideally.
Auto-discovery
It should be achieved via a
.ci/buildbot.nixwhich describes what is the evaluation entrypoint and returns a (potentially deep?) attribute set of derivations, IMHO, requirements:schedule a task to check the main branch (?):
.ci/buildbot.nixScheduled tasks
Via the previous configuration mechanisms, we can describe "scheduled" regular tasks to achieve, e.g. large CI checks and describe notification strategies (?).
TODO:
hydraJobshardcoding in the checks.js pluginAt the moment, buildbot-nix branch
non-flakescan almost work, the scheduling of build requests is broken: https://buildbot.forkos.org/#/builders/3/builds/19 is stuck.We had the builders configured globally, but @delroth said we should not globally set the builders.
While configuring the builders via --builders in the CI, we ran into an issue where we are not allowed to specify the builders because we are not a trusted user.
We worked around this, by copying the .drvs to a single-user store in the working directory and running the build on that single-user store.
But now I'm thinking it would be a lot more elegant to directly run the builds with
--store ssh-ng://$remote-builder, since this would save a lot of copying aroundwe are going for this now, knowing that we are essentially reinventing the nix scheduler: each buildbot job is going to have to decide which (single) remote builder to schedule builds to. in the beginning this will be easy since there is only one remote builder, but it will also have to account for different architectures once we have aarch64.
This solves the issue of the buildbot host's disk running full. Additionally, we'll attach a ?remote-store=/mnt similar to how we are doing it for hydra, and set up a garbage collection job for the store in /mnt on the builder.