In reply to @tomasajt:matrix.org
Is there a way to make hydra not cache a package?
I've seen this discussion: https://discourse.nixos.org/t/how-to-exclude-derivation-in-a-package-closure-from-the-binary-cache/50144

This would be useful for https://github.com/NixOS/nixpkgs/pull/349360, where the vendor directory is not itself a FOD, but constucted from a FOD. This would mean AFAICT that the vendor directory would always be rebuilt when its inputs change, since it's not a FOD, polluting the cache unnecessarily. (The creation of the vendor directory is pretty cheap after you have the FOD)

In reply to @tomasajt:matrix.org
Is there a way to make hydra not cache a package?
I've seen this discussion: https://discourse.nixos.org/t/how-to-exclude-derivation-in-a-package-closure-from-the-binary-cache/50144

This would be useful for https://github.com/NixOS/nixpkgs/pull/349360, where the vendor directory is not itself a FOD, but constucted from a FOD. This would mean AFAICT that the vendor directory would always be rebuilt when its inputs change, since it's not a FOD, polluting the cache unnecessarily. (The creation of the vendor directory is pretty cheap after you have the FOD)

In reply to @ctheune:matrix.flyingcircus.io
Eelco: I'm wondering whether the namedConstituents feature should be working correctly when used recursively ... I'm seeing weird results where a job (release) that has another job (tested) as a constituent that in turn has constituents (the tests) only lists the tested job as a build dependency but not as a constituents and becomes green in hydra before tested actually has all its constituents fulfilled ...