Lemme see what's going on.

Feels like something weird is going on? Or I'm missing something?

https://github.com/loosebazooka/example-build/runs/2908688176?check_suite_focus=true (Expand Run find .)

There doesn't appear to be a bazel-bin/hello_/hello in there?

blaze-* are symlinks. You need to use find -L. Or you can use ls -l bazel-bin/hello_hello.

ah maybe the go code also doesn't follow symlinks

Oh yeah this is definitely the case. I'll fix that.

Ugh. So while I didn't implement symlink resolution when walking a directory provided as the artifact path, the example workflow here provides a file so that shouldn't be the issue.

There is, however, a more frustrating issue going on here with containers and symlinks.

Problem

GitHub Actions runs our provenance generator action in a container as follows:

/usr/bin/docker run \
  --workdir /github/workspace \
  -v "/home/runner/work/example-build/example-build":"/github/workspace" \
  -v "/home/runner/work/_temp/_github_home":"/github/home" \
  --artifact_path bazel-bin/hello_/hello \
  --output_path hello.provenance

The -v volume mount means our bazel directories created in the previous build command should be present as follows:

bazel-bin -> /home/runner/work/_temp/_github_home/.cache/bazel/...```

However the home directory in the container isn't mounted as /home/runner/work/_temp/_github_home but rather /github/home. This breaks the symlink in the home directory created by the bazelisk build command used in the prior step and causes us to get a ENOENT when we try to load the file.

This behavior seems to be corroborated by others: obligatory SO link

Solution

Aside from telling people to avoid symlinks (e.g. by copying files), I'm not sure there's a great solution here. I may be able to add something to detect broken symlinks to improve the error message on our end but the core issue wouldn't really be addressable by us.

An alternative solution would be to reimplement in JavaScript so that you don't need a container at all.