Decide how to handle a symlink inside a remotely produced tree artifact

[tjgq]

Tree artifacts are defined as a collection of regular files. However, a remotely executed action may produce a tree artifact containing a symlink (as reported by the remote execution protocol). The current behavior is to reject such a symlink if it's absolute, and to transparently dereference it to a regular file in the context of the local filesystem if it's relative. This is arguably a bad idea since it's non-hermetic.

Note that transparently dereferencing symlinks isn't necessarily a problem by itself (we also do it for locally executed actions); the fact that action execution and dereferencing occur on different machines is. But sadly there's no mechanism in protocol through which we can request the dereferencing (although, notably, the Google implementation of RBE will always transparently dereference symlinks in action outputs, contrary to the spec).

Note that a similar issue exists for symlinks outside of tree artifacts, but additional considerations apply, since we want (and do allow) actions to produce symlinks that are never dereferenced by Bazel (i.e., declare_symlink).

[tjgq]

I'm going to close this, since recent changes provide a resolution: we will handle symlinks inside a remotely produced tree artifact in the exact same manner as inside a locally produced one (see a03ec7f for details). Although they do introduce a risk of non-hermeticity, this burden is already borne by rule authors, and symlinks are already allowed by file outputs; so there's little value in making local and remote execution divergent.

#15454 still stands as a feature request, but would almost certainly be introduced as a flag, instead of a reinterpretation of preexisting tree artifacts.