Hi, raingloom writes:
> The --dry-run option is the closest thing that I know of. Not sure what > its Scheme equivalent is. Thanks yes - I think this suffers from a similar issue to my own approach in that when a build fails, the store item is removed, along with the test results contained within. So getting the directory was only half the battle. In this case you could use "-K" and have separate logic to deal with success (using a new output) and failure (trawl /tmp for the results) but this strikes me as too complicated. "-K" won't work with build offloading either. And alternative approach I have been looking at is (carefully) using --chroot-directory option on the daemon. It's not ideal as it risks a leaky container, but an extra directory can added to the build container for the sole purpose of test results. It seems to me if I make the directory owned-by but read-only to my build pipeline account (which calls guix and collects the results), and give the directory a group id of guixbuild, but make the group write-only, then I can have a situation where the extra directory doesn't pollute the container, allowing build artifacts to flow outwards only, with no files being able to flow into the build. The problem I see with this is if (like me) you have a machines.scm offloading builds you need a way of retrieving the artifacts off the remote workers (I am assuming they won't sync automatically, but haven't yet tested). A crude solution to this is simply to NFS mount or similar the chroot'ed directory so each worker shares the same directory. Any more comments/ideas welcome - I'll report back if I get something palatable working.
