Sadly I’ve found zero information on this, but when running my own Hydra instance which copies to a (self-hosted RadosGW) S3 bucket in the same way that upstream hydra uses S3 it seems to me that the derivations themselves are not copied into the bucket, only the outputs.
When I nix copy --from the S3 bucket onto a local machine and then run something like nix-diff it will fail with something like this:
nix-diff: /nix/store/sgxx1qkpvnwia4qjyfj4a5q6z9rjwxgn-nixos-system-haskell-24.11.drv: withBinaryFile: does not exist (No such file or directory)
Copying that drv specifically using nix copy $drv will yield:
error: path '/nix/store/sgxx1qkpvnwia4qjyfj4a5q6z9rjwxgn-nixos-system-haskell-24.11.drv' is required, but there is no substituter that can build it
I don’t have a current example for this, but I vividly remember running nix copy on my hydra instance to manually copy some .drv files into the s3 bucket a year or so back because I ran into an issue where I needed those .drv files via the cache (I honestly have no clue why I needed it, but I remember doing it).
Can I somehow convince hydra to copy the .drv files into the S3 bucket such that when I actually need them for whatever reason I can pull them?
Also, is this an issue that only I have due to some other configuration, or is this how hydra works by default?
I no longer have this issue due to some unforeseen effects of a different change.
As I was trying to get per-branch diffing to the main branch (nix-diff and nvd) I had to use hydra’s built-in input types for referencing other job outputs. The issue with eval – while otherwise nice since it keeps the structure – was that nix-diff doesn’t work on it because the nix-store queries regarding derivations are not possible with recursive-nix. sysbuild would incur the trouble of having to reference every output manually. However build has a special property that makes it distinct from sysbuild in that it provides the drvPath in an attribute.
The next thing was to create an aggregate job with constituents which – while not easily replicable locally – doesn’t have access to any of its constituents in its builder, however it does reference them in its .drv file as inputs (to get that job dependency). Now with build this allows me to grab hold of a .drv which references all the constituents that I want to diff in one go, and by virtue of a build job now depending on that .drv file, it will push the entire derivation tree into the S3 bucket as a dependency.
Problem.… well.… not exactly solved, because I doubt that this should be the canonical way to solve this issue, but maybe the information in here gives someone else the last bit of info they need to fix it for themselves (please do report back though), as I don’t need another solution for now.