Open coeuvre opened 2 years ago
@coeuvre Should we flip this flag for 6.0?
As mentioned above:
This flag will NOT be flipped and should be removed once we know that all major remote servers have migrated to the working directory-relative semantic.
We are going to remove this flag from Bazel 8.
Background
REAPI
didn't make it clear for the server implementations on how to interpret the output paths i.e. should the output path relative to input root or working directory? https://github.com/bazelbuild/remote-apis/issues/127With some changes, the spec is now quite clear about output paths being working directory-relative. But some implementations (correctly) implement to the spec, and others implement input root-relative semantics. https://github.com/bazelbuild/remote-apis/pull/191
Bazel changes
Bazel had not been affected by this semantics issue since the
working_directory
field was not set (which implies working directory is input root) until--experimental_sibling_repository_layout
was introduced. When it is enabled, input root will be the parent directory ofexecRoot
, and working directory isexecRoot
.Incompatible flag
--incompatible_remote_output_paths_relative_to_input_root
was then introduced by #13339 to allow projects which enable--experimental_sibling_repository_layout
can be built on remote servers which implement input root-relative semantic.Migration
If you don't use
--experimental_sibling_repository_layout
, no migration is needed.Otherwise, update remote server to the working directory-relative semantic. Before that, set
--incompatible_remote_output_paths_relative_to_input_root
totrue
.Expected timeline
N/A.
This flag will NOT be flipped and should be removed once we know that all major remote servers have migrated to the working directory-relative semantic.
More context