on: tags condition for deploys still not working

[rkh]

No description provided.

[zupo]

Same here, build #1760932 on travis pro.

[Aaron1011]

@rkh: I think this has been fixed now Can you still reproduce this?

[zupo]

Still does not work for me, build #1787204 on travis pro.

[Aaron1011]

@rkh: I believe that I have (finally) fixed it. Can you confirm this?

[zupo]

Still nothing happens (no log output) if I add on: tags: true to my .travis.yml. Build #1993648 on travis pro.

[Aaron1011]

@rkh @henrikhodne: What version of travis-build is deployed on travis-cicom?

[roidrage]

The newest versions of travis-build are deployed, but we're still getting reports of this not working unfortunately.

[zupo]

I can give it another go on my repos today and report back.

[zupo]

Nope, still does not work. Travis Pro, build #2703379, python 2.7, deploying on PyPI.

Works fine until I add "on: tags: true", then the only output for the deploy step is this:

$ git fetch --tags
Warning: Permanently added the RSA host key for IP address '192.30.252.128' to the list of known hosts.
Done. Your build exited with 0.

[roll]

As I wrote in duplicated issue "on" crashes http://lint.travis-ci.org/ (and my lint too). I suppose there will not be a problem to reproduce error for authors.

[roll]

$ travis-lint test (with on:)
/var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:99:in `block in deep_hashrize': undefined method `to_sym' for true:TrueClass (NoMethodError)
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:98:in `each'
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:98:in `inject'
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:98:in `deep_hashrize'
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:105:in `block in deep_hashrize'
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:98:in `each'
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:98:in `inject'
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:98:in `deep_hashrize'
    from /var/lib/gems/2.0.0/gems/hashr-0.0.22/lib/hashr.rb:41:in `initialize'
    from /var/lib/gems/2.0.0/gems/travis-lint-1.7.0/lib/travis/lint/linter.rb:21:in `new'
    from /var/lib/gems/2.0.0/gems/travis-lint-1.7.0/lib/travis/lint/linter.rb:21:in `validate'
    from /var/lib/gems/2.0.0/gems/travis-lint-1.7.0/lib/travis/lint/runner.rb:32:in `block in run'
    from /var/lib/gems/2.0.0/gems/travis-lint-1.7.0/lib/travis/lint/runner.rb:28:in `each'
    from /var/lib/gems/2.0.0/gems/travis-lint-1.7.0/lib/travis/lint/runner.rb:28:in `run'
    from /var/lib/gems/2.0.0/gems/travis-lint-1.7.0/bin/travis-lint:7:in `<top (required)>'
    from /usr/local/bin/travis-lint:23:in `load'
    from /usr/local/bin/travis-lint:23:in `<main>'

[rkh]

That's a bug in travis-lint.

[roll]

I can't find deploy (to PyPi) which falls when I use on: tags: true. But possible it was the same error. I'll try to reproduce.

[pezholio]

Yeah, still not working for me. Trying to deploy to RubyGems with on_tags: true, and I get no output - see:

https://travis-ci.org/theodi/breasal/builds/20697155#L116

[roidrage]

Hey guys, sorry for the delays. I’m currently looking into this issue, will report back with my findings early next week.

[roidrage]

I’ve dug a bit deeper into this issue.

The problem goes a bit further than I originally thought, but I think I at least found a workaround for the time being.

The issue is that, by default, we include an implicit branch condition when checking the on clauses. This condition checks for the default branch, therefore only accepting pushes that match master. But currently, we store the tag name in $TRAVIS_BRANCH. The default check for master will therefore fail, as what’s in the variable is the tag and that doesn’t match the default branches.

So the issue is that we actually set $TRAVIS_BRANCH to the tag’s name, and that we have an implicit branch condition in there, that’s not properly documented.

The temporary fix is to add all_branches: true as a separate condition:

deploy:
  on:
    tags: true
    all_branches: true

I’ll make sure to add this to our documentation.

This relates to #1670.

[Joshua-Anderson]

@roidrage Your workaround will trigger two deployments, one for branch master on a tag, and one for the tag, which can cause problems when deploying things as Travis tries to deploy them twice.

[rkh]

@roidrage Your workaround will trigger two deployments, one for branch master on a tag, and one for the tag, which can cause problems when deploying things as Travis tries to deploy them twice.

Are you sure? Have you tried it?

[eschwartz]

I discovered a workaround for deploying to AWS (and by "discovered", I mean stole from the CloudFoundry wiki:

# .travis.yml
# ...
install:
# do regular install things here
- sudo pip install awscli  #install AWS cli
env:
  global:
    secure: [my encrypted aws keys]
after_success:
  # Check that current branch is master, or quit
  - if [[ "$TRAVIS_BRANCH" != "master" ]]; then echo "Deployments are only done for the master branch. Current branch is $TRAVIS_BRANCH"; exit 0; fi
  - echo "Deploying build $TRAVIS_BUILD_NUMBER"

  # use AWS cli to deploy contents of `build/` to `mybucket` on s3
  - aws s3 cp build/ s3://mybucket --recursive

A little bit more manual labor here, but it works like a charm. It probably won't work for all deployment types, but I hope it helps some of you.

[ryanbillingsley]

Adding all_branches: true fixed the issue i was having with NPM package deployment, 🍻

[Joshua-Anderson]

@rkh:
This build is on master with tagged commit and deploy runs
This build is on tag and deploy runs
This is a normal build on master and deploy doesn't run

[scytacki]

The following might be a work around for the multiple deploy problem. I'm using it in a custom deployment setup.

  CURRENT_TAG=`git describe --tags --exact-match $TRAVIS_COMMIT 2> /dev/null`
  if [ "$TRAVIS_BRANCH" = "$CURRENT_TAG" ]; then
    # this is a tag build
    ...

I haven't tried it with the travis deploy config, but the docs say you can use your own condition. So the above snippet could be condensed to one line, or put in a script. The reference I saw to the custom conditions was the condition option listed here:
http://docs.travis-ci.com/user/deployment/s3/#Conditional-releases

[2m]

Still requires all_branches: true. Tried with deployment to PyPi in this repo: https://github.com/2m/test-pypi-deploy

[BanzaiMan]

Hello, kids! I believe I fixed this with travis-ci/travis-build@28c1b85. This has been deployed. Please test this on your repository. (It worked on my tests, but it might have left some stones unturned.)

Thank you!

[2m]

Thanks. It works on my test repo.

[thedrow]

I'm glad that this issue is finally resolved.

[skiwi2]

Is there now a way to prevent that accidental tags on any branch other than master create a release?
(In an intended situation where only tagging on master creates a new release)

[BanzaiMan]

@2m @thedrow Thanks for the confirmation.

@skiwi2 I am not quite sure what you are describing. Perhaps that merits a new issue?

I'm closing this now, but if you still see a problem, do let us know.

[atomicules]

Hi, still not working for me with PyPi on mrtazz/simplenote.py (I'm a maintainer). Just tried two tagged commits (one lightweight 183221a and one annotated 600595f in case it matters) and Travis is reporting "Skipping deployment with the pypi provider because this is not a tagged commit". It could well be something I'm doing wrong, but I'm stumped as to what. I notice via 'travis requests' I do have a couple of builds that say "received (validation pending)" if that means anything?

[BanzaiMan]

@atomicules Neither https://travis-ci.org/mrtazz/simplenote.py/builds/50820565 nor https://travis-ci.org/mrtazz/simplenote.py/builds/50827064 is a tagged build. You are only building the master branch (https://github.com/mrtazz/simplenote.py/blob/600595fe9582e0ad4781fe533e8accddc8f81082/.travis.yml#L5-L7). You should change that.

See also https://travis-ci.org/mrtazz/simplenote.py/requests

[atomicules]

@BanzaiMan thank you for pointing that out to me. I have fixed that and it is now trying to deploy now, but failing with: "invalid option "--password=""

[BanzaiMan]

@atomicules Sounds like your encrypted password was not decrypted correctly. Please review the documentation.

[atomicules]

@BanzaiMan we re-added the password and deploys are now working. Thank you very much for your responses.

[vaibhavsagar]

I'm getting nowhere with my attempts to use releases, even after adding all_branches: true on my repo. Travis is also giving me a 'branch not included or excluded' error with my attempts to push up tags, am I doing this wrong?

[atomicules]

@vaibhavsagar Looks like the same mistake I made. Remove these lines and try it again.

[vaibhavsagar]

That worked! Thanks so much @atomicules!

[chrisbaldauf]

I'm just getting started with travis and npm deployments and I am having trouble getting travis to push to npmjs.com on tagged commits, seeing the same behavior as described in this ticket. Hopefully someone can point out something obvious that I'm missing.

• travis.yml
• build output

Result: Skipping a deployment with the npm provider because this is not a tagged commit

I added "all_branches: true" per the workaround instructions in this issue.

My process for committing / pushing was

echo "..." >> README.md
git commit -am "comment"
npm version patch
git push origin master --tags

Thanks in advance for any direction or advice you might be able to provide.

[BanzaiMan]

@chrisbaldauf Sorry to hear about this issue. I think it's a separate issue, though, so please open a new issue.