Artifact with no file extension uploaded to an incorrect path

bengotow commented 7 years ago

I'm working on an open-source project and have several artifacts configured in .travis.yml:

addons:
  artifacts:
    working_dir: app/dist
    target_paths: client/${TRAVIS_COMMIT:0:8}/${TRAVIS_OS_NAME}
    permissions: public-read
    paths:
    - mailsync
    - mailsync.dSYM.zip
    - Merani.dmg
    - Merani.zip
    - $(find . -type f -name *.deb | tr "\n" ":")
    - $(find . -type f -name *.rpm | tr "\n" ":")

In my case, mailsync is an executable, and mailsync.dSYM.zip contains the debug files for the executable. When the Travis build completes, it finds the files and claims to upload them, but chooses an incorrect path for the mailsync file without an extension:

Uploading Artifacts (BETA)
artifacts.setup
artifacts version v0.7.8-26-gd62580b revision=d62580ba6bfffc7245d8ac6a1a384ef60b9302e7
$ export ARTIFACTS_PATHS="mailsync:mailsync.dSYM.zip:Merani.dmg:Merani.zip:$(find . -type f -name *.deb | tr \"\\n\" \":\"):$(find . -type f -name *.rpm | tr \"\\n\" \":\")"
$ artifacts upload
INFO: uploading with settings
  bucket: [secure]
  cache_control: private
  permissions: public-read
INFO: uploading: app/dist/mailsync.dSYM.zip (size: 5.8MB)
  download_url: https://s3.amazonaws.com/[secure]/client/7191c2e8/osx/mailsync.dSYM.zip
INFO: uploading: app/dist/mailsync (size: 5.1MB)
  download_url: https://s3.amazonaws.com/[secure]/client/7191c2e8/osx
....

The second download URL should be https://s3.amazonaws.com/[secure]/client/7191c2e8/osx/mailsync not, https://s3.amazonaws.com/[secure]/client/7191c2e8/osx.

I'm not sure how to fix this in the meantime—anyone have ideas?

Here's a full build log illustrating the problem: https://travis-ci.org/Foundry376/Merani/jobs/264519025.

bengotow commented 7 years ago

I think I may have figured this out. When the Artifacts script runs, the working copy contains a folder with the name mailsync at the top level, as well as the compiled executable at app/dist/mailsync.

I think the name overlap is causing a pretty obscure bug. I believe this IsDir method (https://github.com/travis-ci/artifacts/blob/master/path/path.go#L36) should be calling os.Stat(p. Fullpath), not p.From, and because there /is/ a directory at p.From, it adds p.From to p.Root here: https://github.com/travis-ci/artifacts/blob/d62580ba6bfffc7245d8ac6a1a384ef60b9302e7/upload/uploader.go#L153

and then replaces it down to nothing and sets dest to "" here:

https://github.com/travis-ci/artifacts/blob/d62580ba6bfffc7245d8ac6a1a384ef60b9302e7/upload/uploader.go#L173

I unfortunately don't know Rust so I'm afraid I can't easily make a failing test case, but I'm going to try renaming the artifact to another name (still without an extension) to see if I can verify.

bengotow commented 7 years ago

Just to follow up—I've confirmed that removing/renaming the top-level mailsync directory fixes this issue and results in app/dist/mailsync being uploaded to a correct remote path.

eukreign commented 6 years ago

Experienced the exact same problem. The root project directory contains a folder which is the same name as the binary that is in ./dist/ directory.

travis-ci / artifacts

Artifact with no file extension uploaded to an incorrect path #78