Open ryanrf-ac opened 4 years ago
I just tried this with version bazel version 1.1.0 and I have the same results.
@ryanrf-ac Did you ever get it to work? I'm also coming across this issue using Hugo v0.74.3. There's some discussion around a change on v0.56.0 which broke this behaviour.
It looks like this project is no longer maintained, so it might be worth making a fork.
Perfect! Thanks for the reference.
I think this is more of a shame on Hugo's part, rather than the rules. I can't really understand why they would disallow symbolic links.
@uhthomas I think this is a mixture of both hugo and bazel. Bazel is choosing to fallback on creating a sandbox using symlinks to run everything from what it considers a safer location. Ideally, the sandbox would using isolation techniques like namespacing and cgroups, which can be used on linux, but on mac there's no such luck. I feel like getting sandboxfs to work would also be another solution here that would avoid symlinks, but I couldn't get that working, and the only docs I could find were a few years old.
From Hugo's point of view, my understanding is that symlinks can invite unwanted access in some cases, and can be messy. So discouraging their use makes sense, but I agree, preventing the use of symlinks seems a bit aggressive.
I realize this sounds a bit like the first issue on this repo, but I'm a bit unclear why
execution_requirements = {'no-sandbox'}
was removed. @gertvdijk could you please elaborate?I'm hitting this issue, where Hugo is complaining about symlinks. I realize this is Bazel creating symlinks in an attempt to sandbox the inputs, but I'm not clear on how to resolve it. When I added
execution_requirements = {'no-sandbox'}
bazel was able to build my site successfully.I should add that I'm using Bazel 0.26, so perhaps @gertvdijk's fix was related to a later version. I also realize that the
.bazelversion
in this project has 1.1.0, so maybe this is a bit of a shot in the dark for me. I'm also using Hugo 0.73.0. The specific error I'm getting is