Setting environment variables without affecting action cache key

[Alexandr Burdiyan]

I'm an experienced Bazel user, and I know what I'm looking for is a giant footgun, but I still want it. So I wonder maybe there's a good way of achieving this that I somehow missed in all these years.

I would like to pass some key value pair to an action without affecting the cache key of this action. I don't care if it's an environment variable, a file, or whatever. I'm pretty sure there's no built-in way for that in Bazel, but maybe there's some trick that could be exploited.

My use case is that I have a hermetic and reproducible dev environment with Nix, in which I declare all my tools. So I'd like to expose those tools to my Bazel actions, but do so in such a way that if the path to those tools is different across different machines, the action could reuse the remote cache.

[David Turner]

Can you create an external repository with symlinks to your host-specific tools, then use labels like @host_tools//:tool_name in your action?

Since Bazel always follows symlinks, if the tool binaries are the same (byte wise), this will result in the same action cache key, as far as I understand, independent of their actual installation location.

Of course, this would not work if the tools are not byte-wise identical though, but then I'd say you are asking for trouble :-)

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/fc12a1da-1bb2-40ea-88ce-c0a8a28024b5n%40googlegroups.com.

[Alexandr Burdiyan]

I was going to do exactly that, but I got confused into thinking that Bazel wasn't following symlinks created by `repository_ctx.symlink`. Turns out actions that use those symlinks in inputs do get rebuilt when the source file the symlinks points to change, but the repository rule that creates the symlink doesn't get re-evaluated, despite being configured with `local = True` (which is now unsurprising to me after I realized it).

Thank you!

[Jared Neil]

If I'm reading your question correctly, I think you may be able to do this this with stamping and the `volatile-status.txt` file created from the workspace status command.

[Alexandr Burdiyan]

Wouldn't `volatile-status.txt` still be an input to the action that uses it, and still affect the action key? I guess it wouldn't affect the caching (i.e. if `volatile-status.txt` is the only input of the action that was changed, the action wouldn't fire), but it would still affect the hashing of the action key?