Sass builds are not hermetic

[MHordecki]

It looks like sassc happily imports files not specified in the deps argument of a sass_binary. To observe this, remove the two deps from the BUILD definition of //examples/hello_world:hello_world and see that the target is still building successfully.

bazel version:

Build label: 0.2.1-homebrew
Build target: bazel-out/local_darwin-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Apr 1 00:35:17 2016 (1459470917)
Build timestamp: 1459470917
Build timestamp as int: 1459470917

[stoltene2]

I do not see this problem anymore @MHordecki.

$ bazel build //examples/hello_world
INFO: Analysed target //examples/hello_world:hello_world (1 packages loaded).
INFO: Found 1 target...
ERROR: /Users/stoltene/workspace/external/rules_sass_git/examples/hello_world/BUILD:6:1: SassCompiler examples/hello_world/hello_world.css failed (Exit 1)
Error: file to import not found or unreadable: examples/shared/fonts
       Current dir: /private/var/tmp/_bazel_stoltene/eea42f593c6e53b2981b19d96cc421c3/bazel-sandbox/8710847650644111769/execroot/io_bazel_rules_sass/examples/hello_world/
        on line 1 of examples/hello_world/main.scss
>> @import 'examples/shared/fonts';
   --------^

bazel version:

Build label: 0.10.0-homebrew
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jan 9 21:07:27 +50057 (1517479996047)
Build timestamp: 1517479996047
Build timestamp as int: 1517479996047

[zaucy]

I've been using rules_sass heavily recently and I noticed on my machine (running windows) if I comment out the dependencies of //examples/hello_world:hello_world it still compiles.

$ bazel build examples/hello_world
DEBUG: Rule 'bazel_skylib' indicated that a canonical reproducible form can be obtained by modifying arguments shallow_since = "1542823465 -0500"
DEBUG: Call stack for the definition of repository 'bazel_skylib' which is a git_repository (rule definition at C:/users/zekew/_bazel_zekew/c2nhtrs7/external/bazel_tools/tools/build_defs/repo/git.bzl:195:18):
 - D:/source/rules_sass/package.bzl:22:9
 - D:/source/rules_sass/package.bzl:37:5
 - D:/source/rules_sass/WORKSPACE:5:1
INFO: Analyzed target //examples/hello_world:hello_world (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //examples/hello_world:hello_world up-to-date:
  bazel-bin/examples/hello_world/main.css
  bazel-bin/examples/hello_world/main.css.map
INFO: Elapsed time: 0.147s, Critical Path: 0.01s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action

The modified sass binary looks like this

sass_binary(
    name = "hello_world",
    src = "main.scss",
    deps = [
        # "//examples/shared",
    ],
)

Bazel version:

$ bazel version
Bazelisk version: v1.0
Build label: 0.29.0
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Aug 28 14:35:37 2019 (1567002937)
Build timestamp: 1567002937
Build timestamp as int: 1567002937

[nex3]

I can reproduce this, but I'm not enough of a Bazel expert to figure out why it's not hermetic. @alexeagle can you take a look?

[alexeagle]

node module resolution by default will walk up the filesystem tree to find dependencies. also, some node programs do a realpath to resolve symlinks so they hop outside Bazel's sandbox directory.

It's possible that this could be fixed with --preserve-symlinks and/or --preserve-symlinks-main option being passed to the node execution that runs sass (like in the templated_args of the nodejs_binary, see https://github.com/bazelbuild/rules_nodejs/blob/master/docs/Built-ins.md#templated_args)

If your sass action runs in a worker (it should by default on recent Bazel versions) then adding --worker-sandboxing flag to Bazel should give you a stronger sandbox where these files aren't visible to the action.

The strongest sandboxing is with remote build execution, which you can run locally, see https://docs.bazel.build/versions/master/remote-execution-sandbox.html