Deleting a project in hydra

I created a project in hydra with a single jobset, after a while I reconsidered this decision and wanted to have the builds of that job set in another project.

Already before that I assumed I can not just “move” the jobset over but have to delete the old jobset and project and create the jobset anew in the target project.

Creating in the target project was not an issue, but now I have the old jobset lingering in the initial project and I can not delete the jobset, as it seems this functionality isn’t exposed in the UI, when trying to delete the project I see the following error in a modal:

{UNKNOWN}: Can’t locate object method “jobsetevals” via package “Hydra::Model::DB::Projects” at /nix/store/494sfr87x2528zjb4r9ryg7ffz4jg213-hydra-2021-03-10/libexec/hydra/lib/Hydra/Controller/ line 81. at /nix/store/494sfr87x2528zjb4r9ryg7ffz4jg213-hydra-2021-03-10/libexec/hydra/lib/Hydra/Controller/ line 84

1 Like

AFAIK you can only disable jobs, which hides them from view. This is by design… probably to stop accidental erasure of jobs.

You can clone a job , into a new jobset… thats probably what your looking for.

Okay, so the only way to eventually get rid of the built artifacts, is to actually set the jobset to keep 0 evaluations and wait for them to become GC’d?

As the 50GiB worth of built artifacts is what gives me headaches…

I do it the caveman way , and remove the gcroots from


basically i blat that directory, and then


This is a horrible hack and i don’t really recommend it for production systems, but it works
for testing. So if you do this and you machines melts into a blackhole… then you’ve been warned.

Doing a systemctl start hydra-update-gc-roots.service followed by a regular nix-collect-garbage did indeed drop the pathes that are not also used by “alive” configuration.

And luckily this is not a production system, it is just my daily driver :wink: I use it to experiment with hydra, hoping to eventually use hydra on a dedicated host later on to maintain some auto-updated flake for system and user configuration eventually.


let us know your progress. i’ve got smaller projects to build from flakes on hydra, but not sure how you can build a flake that describes a entire system yet. I’m taming the hydra one head at a time :slight_smile:

Describing the whole system is easy with the nixosConfigurations output.

Getting them built by hydra is similarily easy:

checks.x86_64-linux = builtins.mapAttrs (_: hostConfig: self.nixosConfigurations;

It is the other stuff I haven’t really managed to do yet…

Like regularly polling the inputs and updating them on the flake, updating the lockfile, pushing to a branch once built… automatic merge from a “dev” branch to master/main once the builds succeeds and pushing back to GitHub, etc…

And of course, using it as a binary cache


Did you ever find out how to update a flake lockfile? I’m trying to get hydra to build all my systems with each update to the unstable branch, but haven’t figured out how to do it yet.