feat: support raw symlinks from declare_symlink()

[rickeylev]

Using the ctx.actions.declare_symlink() API, rules can create explicit symlinks to arbitrary
paths, which Bazel will keep as symlinks. The packaging logic treats these
as regular files, so tries to read through them and store the content they point to. This
is incorrect for two reasons: they are supposed to be left as symlinks and may be dangling
symlinks from the perspective of packaging.

To fix, introduce a new type of file entry: raw_symlink. These entries mean the src is
a symlink whose stored path should be stored into the destination verbatim, also as a symlink.
Such artifacts are identified using File.is_symlink, a Bazel 8+ API.

Work towards #929

[cgrindel]

Can we add a test for this?

[rickeylev]

Ok, it's been awhile since I could get time to come back to this!

I've added a basic test. PTAL.

[rickeylev]

OK, PTAL.

I fixed the buildifier presubmit failure.

The other failure looks unrelated -- I get the same error at clean head. It's specific to the rolling version of bazel and something about workspace support.

[rickeylev]

Actually, I partially take that back -- The LTS windows test is failing. Some quick searches indicates windows symlink support should work fine with the values the test is using (relative symlinks that point nowhere).

Diagnosing and fixing this will be a bit hard, but I'll see what I can do. If it comes to it, can we simply mark this test to skip windows?

[meteorcloudy]

https://bazel.build/configure/windows#symlink
Do you have --windows_enable_symlinks specified as a startup flag? Otherwise a junction might be created instead of a symlink, which doesn't support relative path.

See https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/windows/WindowsFileSystem.java;l=83-92

[rickeylev]

I tried adding --windows_enable_symlinks, but that didn't fix it.

So far, all I can tell is that, when tar building occurs, and python calls os.readlink() to figure out the value contained in the symlink, it gets back an absolute path e.g. \\?\C:\b\3ctu2esx\execroot\_main\bazel-out\x64_windows-fastbuild\bin\tests\tar\link1. That is the correct resolved path (foo_link1 -> ./link1), but yeah, we don't want the resolved path.

I can't tell which of these cases is happening:

1. Bazel is writing an absolute path
2. Windows is silently transforming it to an absolute path at write
3. Windows is silently transforming it to an absolute path at read
4. Python is transforming it to an absolute path

I won't have direct access to a windows machine until this evening, so I'll have to wait until then to check some of these ideas.

But overall, this isn't sounding promising. I don't think we can work around (1) or (2). A work around for (3) and (4) might be possible by using e.g. ctypes and dropping into lower-level APIs.

[rickeylev]

After testing on my personal windows machine, I'm thinking its (1: Bazel writing an absolute path). I can use mklink to create relative symlinks, and python's os.readlink() returns the relative path correctly. When I use an absolute path, it returns a \\?\... looking string, the same as what I'm observing.

[rickeylev]

Aha, here we go. known issue in Bazel specific to windows: bazelbuild/bazel#14224

[meteorcloudy]

OK, I guess let's disable the test on Windows for now

[rickeylev]

Tests fixed. PTAL

[rickeylev]

bump -- this has been sitting for awhile; is there an ETA on when someone can review?

[cgrindel]

bump -- this has been sitting for awhile; is there an ETA on when someone can review?

In the future, if you hit the "Re-request review" button, that will let the reviewer who has left comments look at the PR again. Looking now

[cgrindel]

LGTM. @aiuto Did you want to look before we merge?

[rickeylev]

Oh, i had not noticed that thingy before. Done, for at least my own practice :). Thanks!