rules_rust
rules_rust copied to clipboard
bazelbuild
feat: make source path prefix configurable
Currently, the rules apply the --remap-path-prefix=${pwd}=. substitution when building inside a sandbox.
Sometimes this substitution causes non-determinism in our CI setup.
Specifying a fixed path prefix, such as /source/, resolves the non-determinism issue (at least on Linux).
This change allows configuring the prefix via the @rules_rust//:source_path_prefex option, leaving the current behavior as default.
Currently, the rules apply the
--remap-path-prefix=${pwd}=.substitution when building inside a sandbox. Sometimes this substitution causes non-determinism in our CI setup.
It's non-deterministic because the sandbox path gets embedded in binaries? Or rlibs?
It's non-deterministic because the sandbox path gets embedded in binaries? Or rlibs?
In the final binaries, that's how we caught the non-determinism in the first place: we check determinism on CI by building inside of a docker container on several Linux machines and comparing the resulting binaries.
Some rlibs might also have been different, I don't have the data ATM.
Would this issue ultimately be fixed by this feature?
- https://github.com/rust-lang/rust/issues/89434
I don't think users should need to disable sandboxing to achieve deterministic outputs but am not sure what the rules can do if the problem is actually in rustc.
The nondeterminacy is surprising, especially on linux. Having the path prefix seems reasonable, but I'd like to understand better the source of the nondeterminacy, e.g., is it coming from rustc itself or from some interaction in rules_rust. Could you share a toy example that reproduces the non-determinacy manually in some way? Maybe also do you have the means to examine the differences between the binaries, I suspect something like diffing the strings occuring in them could give us some more hints where the nondeterminacy comes from. We've seen recently some artifacts where the short_path to a thingy outside of the main bazel repository you're working in sometimes starts with .., requiring some care here and there. I wouldn't be surprised if something like this inside rules_rust itself is a source of such nondeterminacies...
I'm not inherently opposed to this PR, but the nondeterminism issue is likely to actually be #1536. I don't see how this PR could help prevent Bazel paths from making it into the output.
