GitHub releases fails to deploy when supplied glob matches a subdirectory

[luckyrat]

Use a config file like this:

deploy:
  - provider: releases
    api_key:
      secure: "foo"
    file_glob: true
    file: dist/**/*
    skip_cleanup: true

With a build output filesystem structure like this:

- $TRAVIS_BUILD_DIR
 - dist
  - file1
  - dir1
   - file2

Expected behaviour

file1 and file2 are uploaded to a new GitHub release.

Actual behaviour

file1 is uploaded and then the build fails with a stack trace like this:

/home/travis/.rvm/gems/ruby-2.2.7/gems/octokit-4.6.2/lib/octokit/client/releases.rb:94:in `read': Is a directory @ io_fread - dist/signed (Errno::EISDIR)
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/octokit-4.6.2/lib/octokit/client/releases.rb:94:in `upload_asset'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-releases-1.9.1/lib/dpl/provider/releases.rb:130:in `upload_file'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-releases-1.9.1/lib/dpl/provider/releases.rb:111:in `block in push_app'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-releases-1.9.1/lib/dpl/provider/releases.rb:102:in `each'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-releases-1.9.1/lib/dpl/provider/releases.rb:102:in `push_app'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.9.1/lib/dpl/provider.rb:194:in `block in deploy'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.9.1/lib/dpl/cli.rb:41:in `fold'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.9.1/lib/dpl/provider.rb:194:in `deploy'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.9.1/lib/dpl/cli.rb:32:in `run'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.9.1/lib/dpl/cli.rb:7:in `run'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.9.1/bin/dpl:5:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.2.7/bin/dpl:23:in `load'
	from /home/travis/.rvm/gems/ruby-2.2.7/bin/dpl:23:in `<main>'

Additional information

I think that the issue can also be reproduced with a glob of dist/* and the above build output directory structure (i.e. we don't actually want to upload anything inside the subdirectory but it's mere presence causes the build to fail). I think this because I saw the same error when I had a config like the one below and can't see how the 2nd file entry could be the cause of the error.

deploy:
  - provider: releases
    api_key:
      secure: "foo"
    file_glob: true
    file:
	  - dist/*
	  - dist/signed/*
    skip_cleanup: true

Note that this bug means that the documentation update pending in PR travis-ci/docs-travis-ci-com#1750 from @alexmozzhakov does not work.

Example failed builds

My first exposure to this bug (with the multiple file entries):
https://travis-ci.org/kee-org/browser-addon/builds/353727668

My failed attempt to avoid the bug by using the dist/**/* glob:
https://travis-ci.org/kee-org/browser-addon/builds/353742834

Potential workaround

If you can predict something constant about the built files you can avoid this bug by changing the glob as per the example config below (where we know that we are only interested in files with specific extensions)

deploy:
  - provider: releases
    api_key:
      secure: "foo"
    file_glob: true
    file: "dist/**/*.{xpi,zip}"
    skip_cleanup: true

[ghost]

This is the correct link to PR -> travis-ci/docs-travis-ci-com#1750
Also have a look at #9322

[luckyrat]

This is the correct link to PR

Thanks. Updated my link.

[BanzaiMan]

I think this is a bug, after all, which I should have spotted in #9322. Regardless; the releases provider is descending into directories, and processing them all, but it's also trying to upload everything, whether it is a normal file or a directory (which can happen if the specified directory has nested directories underneath). This should be fixed.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 24 hours. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues