Action can't find the artifact

[MarkLodato]

The action does not work because it cannot find the artifact. To reproduce, see https://github.com/MarkLodato/example-build and an example run. The slsa-framework/github-actions-demo@v1 step fails with the following error:

Resource path not found: [provided=bazel-bin/hello_/hello]

(This step has continue-on-error: true so the rest of the workflow succeeds.)

The file definitely exists and is picked up correctly by the upload-artifact step.

[loosebazooka]

Lemme see what's going on.

[loosebazooka]

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?

[MarkLodato]

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

[loosebazooka]

ah maybe the go code also doesn't follow symlinks

[msuozzo]

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

[msuozzo]

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.

[MarkLodato]

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