support a more selective watch mode via a queue+socket+post-build-hook

[colemickens]

Idea:

I really want to capture build outputs as they're produced, but I don't really like that cachix watch picks up things from unrelated builds.

It seems like this be fixed by utilizing a post build script. However, I don't like configuring it on the daemon because it's one extra step to do on remote builders, it would catch "all" builds again, and I try to keep my "buildargs" portable so that I always get cache hits, etc (this might be alleviated once flakes respects custom nix conf).

But, it seems like we would need to "queue" the signing+pushing still and do it out-of-band from the builds. That's where cachix can play a role:

1. Start cachix, listen on a socket, sign+push paths when told about them over the socket
2. Let the user use the post-build-hook to send paths to that socket on success nix build

# untested, example (can't remember if I need to force it to not interpolate OUT_PATHS yet)

cat<<EOF >/tmp/script.sh
echo "${OUT_PATHS[@]}"  | cachix --queue-socket /tmp/cachix.sock"
EOF

cachix --watch-socket /tmp/cachix.sock
nix build '.#hello' -L --option post-build-hook "/tmp/script.sh"

[domenkozar]

Is post-build-hook executed on the client or daemon side?

[domenkozar]

(you probably mean cachix where you say cargo?)

[colemickens]

yes, s/cargo/cachix/g, updated the original post.

I'm not sure if it's executed client side or daemon side, but if I stash whoami in the post-build-hook into a file and then check it, it says root...

[domenkozar]

Yeah I agree with this and I plan to experiment how feasible it is. I've laid down a plan in #53 and this is on the horizon soon!

https://hackage.haskell.org/package/stm-2.5.0.0/docs/Control-Concurrent-STM-TChan.html

[domenkozar]

Here's the plan how this will work:

Using async to start two concurrent threads. The first thread is doing stuff and feeding things to a channel. The second one is consuming from channel and doing things based on those message. To handle done case: data Message = Done | Do Thing would be the message passed, so second thread would exit on Done case.

I have then yet to figure out how to handle CTRL-C but this makes the happy case smooth.

[domenkozar]

Going to start next week.

[domenkozar]

Queue implemented in #353, what's left then is the interface for post-build-hook and sockets.

@colemickens are you sure that post-build-hook works when specified on the client?

[colemickens]

Yes. I've implemented this in my own tool that has some other big differences from cachix. We can share notes later if you want.

…

On Tue, Jan 5, 2021, 03:34 Domen Kožar ***@***.***> wrote: Queue implemented in #353 <#353>, what's left then is the interface for post-build-hook and sockets. @colemickens <https://github.com/colemickens> are you sure that post-build-hook works when specified on the client? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACP25AXZ46HMGG7CQFRFOLSYL2LBANCNFSM4TIF2GLA> .

[domenkozar]

Cool - I'm going to implement push-run first and then also the build hook handling. Happy to compare - one thing that cachix does well is that it ensures whole closure is present in the cache.

[domenkozar]

Prioritizing this one as it's needed for https://github.com/cachix/cachix-deploy-hetzner-dedicated