We have had a few requests to support unresolved symbolic links, but so far, we have managed to live without.
The use case is creating packages and file system images where one has a symlink (for example/bin/bash) and the desired result is not to package up the file the symlink points to (in this case, the shell of the system the action runs on), but to put the actual symlink /bin/bash in the package.
RBE wisely decided to implement this ahead of time, which is good.
I expect there to be some trouble with Windows, but other than that, the change should be relatively straightforward.
We might run in to trouble if we want to support unresolved symlinks within tree artifacts: whether the symlink needs to be resolved may need to be decided on a per-file basis and it's not trivial to convey that information to Bazel. However, we'll cross that bridge when we get to it.
We have had a few requests to support unresolved symbolic links, but so far, we have managed to live without.
The use case is creating packages and file system images where one has a symlink (for example
/bin/bash) and the desired result is not to package up the file the symlink points to (in this case, the shell of the system the action runs on), but to put the actual symlink/bin/bashin the package.RBE wisely decided to implement this ahead of time, which is good.
I expect there to be some trouble with Windows, but other than that, the change should be relatively straightforward.
We might run in to trouble if we want to support unresolved symlinks within tree artifacts: whether the symlink needs to be resolved may need to be decided on a per-file basis and it's not trivial to convey that information to Bazel. However, we'll cross that bridge when we get to it.