Failing to upload artifacts from symbolic link directories

artifacts
#1

I’ve been trying to store_artifacts with a path that is itself a relative symbolic link, e.g:

/opt/ws/log# ls -al
drwxr-xr-x  3 root root 4096 Jan 23 01:39 .
drwxr-xr-x  1 root root 4096 Jan 23 01:39 ..
drwxr-xr-x 29 root root 4096 Jan 23 01:41 test_2019-01-23_01-39-12
lrwxrwxrwx  1 root root   12 Jan 23 01:39 latest -> latest_test
lrwxrwxrwx  1 root root   25 Jan 23 01:39 latest_test -> test_2019-01-23_01-39-12

However, it seems that CircleCI doesn’t resolve this path:

Uploading /opt/ws/log/latest_test to opt/ws/log/latest_test
Uploading /opt/ws/log/latest_test (4.1 kB): FAILED with error BodyHashError: failed to compute body hashes
caused by: read /opt/ws/log/latest_test: is a directory

So far I’ve been working around this by duplicating the logs first, but this step seem unnecessary:

steps:
  - run:
      name: Duplicate Test Logs
      when: always
      command: cp -rH log/latest_test log/test
  - store_artifacts:
      path: log/test
#2

Could I get any confirmation as to if this is expected behavior or indeed a bug? :beetle:

#3

Hi there. Sorry for the delay in responding. Do you get the same error if you add a slash, such as

  - store_artifacts:
      path: log/test/

I suspect the link -> link -> link is confusing things, but I haven’t checked the code yet.

#4

Like so:

  - store_artifacts:
-      path: path: log/build
+      path: path: log/build/

Same error… See the setup, commit and error here:

https://circleci.com/gh/ruffsl/navigation2/93#artifacts/containers/0

#6

After some digging, it turns out the S3 SDK, which we use to upload artifacts, can not handle a double-symlink like you are using here. It will upload the second symlink, not the final target, and then break.

#7

Ok. Is there a programmatic manner that I could resolve the symlink path and tell ‘store_artifacts’ which expanded unique path to store? Is this a use case for dynamicly setting paramaters and passing them to wrapper functions in the config file?

#8

I think the extra workaround step you mentioned in the first post is probably the simplest way.

#9

Alright then, I’ll just stick with my extra workaround. Thank for digging into this @drazisil !