target_paths option in .travis.yml is ignored

[mfornasa]

It seems that the option --target-paths is missing from artifacts.go.

[meatballhat]

@mfornasa Thanks for the report! Fixing...

[meatballhat]

@mfornasa (now that I've checked) If you're looking for a literal --target-paths, you won't find it. Instead, the codegangsta/cli library expects a string of comma-delimited flag "names", which are automatically prepended with -- or - depending on the number of characters in the name, e.g.: https://github.com/travis-ci/artifacts/blob/970821da610c7317795af1fdf5c3a30342c7157e/artifacts.go#L96-L101

Are you experiencing a specific error at runtime?

[mfornasa]

Wihtout specifying the target:

$ ./artifacts  upload --key [...] --secret [...] --bucket test  /home/developer/p.sh
INFO[0000] uploading with settings                       bucket=test cache_control=private permissions=private
INFO[0000] uploading: /home/developer/p.sh (size: 39B)   download_url=https://test.s3.amazonaws.com/artifacts/home/developer/p.sh

Using env var (works):

$ ARTIFACTS_TARGET_PATHS=PP  ./artifacts  upload --key [...] --secret [...] --bucket test  /home/developer/p.sh
INFO[0000] uploading with settings                       bucket=test cache_control=private permissions=private
INFO[0000] uploading: /home/developer/p.sh (size: 39B)   download_url=https://test.s3.amazonaws.com/PP/home/developer/p.sh

Using --target-paths (doesn't work)

$ ./artifacts  upload --key [...] --secret [...] --bucket test --target-paths "PP" /home/developer/p.sh
INFO[0000] uploading with settings                       bucket=ct-build-cleverhire cache_control=private permissions=private
INFO[0000] uploading: /home/developer/p.sh (size: 39B)   download_url=https://test.s3.amazonaws.com/artifacts/home/developer/p.sh

[meatballhat]

@mfornasa got it. I'll take a look! Thank you so much for the details :smiley_cat:

[mfornasa]

Thanks. A related question (I think). I'm using artifacts as travis addon as shown here and I'm having problems with --target-paths. Is this the same issue as above? (That is, are the .travis.yml directives translated to command line parameters?)

[meatballhat]

@mfornasa do you have an example build I can see? If it's a private build, would you be willing to gist up a sanitized version of the log?

[mfornasa]

Here three examples using:

• target-paths: test
• target_paths: test
• env: ARTIFACTS_TARGET_PATHS=test

[mfornasa]

On this last issue I had an answer from Travis support:

At this point it's not possible to choose the destination paths. We're working on a better integration of these files in our user interface and having unique means of recognizing and linking to the files uploaded is part of this.

If you need better configurability, maybe the S3 deployment would work better? http://docs.travis-ci.com/user/deployment/s3/

[meatballhat]

@mfornasa Ah, so I'm guessing this is due to target_paths being a "controlled param" (https://github.com/travis-ci/travis-build/blob/1d6ded37cf22d798a0c3c2642e4d0ec646670df1/lib/travis/build/script/addons/artifacts.rb#L93-L100) The suggestion to use the S3 deployer is valid, or you could choose to use the artifacts executable directly, e.g.:

# ...
env:
  global:
  # secure ARTIFACTS_KEY definition
  - secure: ...
  # secure ARTIFACTS_SECRET definition
  - secure: ...
  # other ARTIFACTS_* vars
  - ARTIFACTS_TARGET_PATHS=test
  - ARTIFACTS_DEBUG=1
after_success:
- curl -sL https://raw.githubusercontent.com/travis-ci/artifacts/master/install | bash
- ~/bin/artifacts upload

[meatballhat]

@mfornasa in one of your comments above you have some invocations that look you're running ./artifacts directly, but later on you reference build logs that are using the .travis.yml integration. Are you experiencing issues with target paths in both cases?

[meatballhat]

@mfornasa bump :smiley:

[0x6e6562]

Is this issue still current? I'm in the process of porting from the artifacts gem to the addon and I'm trying to specify a particular target path, but it seems that this is just getting ignored and there are no useable diagnostics to see where this might be going.

[meatballhat]

@0x6e6562 I believe this is "fixed" now in the addons.artifacts implementation via https://github.com/travis-ci/travis-build/commit/aa34739647430c6cb595b0f26921f63b9d7c7bd4. Pretty please can you confirm?

[0x6e6562]

@meatballhat Sorry for the radio silence :-(

I can confirm that this issue is now fixed on Travis CI, so thank you very much for patching this :-)

For anybody else reading this thread, here is the relevant part of my descriptor:

addons:
  artifacts:
    debug: true
    paths:
      - PATH_TO_MY_ARTIFACT
    target_paths: PATH_WITH_MY_S3_BUCKET/$TRAVIS_BUILD_NUMBER
    working_dir: WORKING_DIR
    bucket: MY_S3_BUCKET
    s3_region: eu-west-1

Note that I am using the repository creds for this, as set using the travis gem:

$ travis env set AWS_SECRET_KEY fmAQd46zn2euqA827da3nb89c9 -r owner/repo

To check the creds for a repo:

$ travis env list -r owner/repo       
# environment variables for owner/repo
AWS_ACCESS_KEY=[secure]
AWS_SECRET_KEY=[secure]

[0x6e6562]

Given that it works now, I would suggest that we close this issue now?

[meatballhat]

@0x6e6562 Thanks so much! :heart_eyes_cat: