Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

on: tags condition for deploys still not working #1675

Closed
rkh opened this issue Nov 26, 2013 · 72 comments
Closed

on: tags condition for deploys still not working #1675

rkh opened this issue Nov 26, 2013 · 72 comments
Labels

Comments

@rkh
Copy link
Member

@rkh rkh commented Nov 26, 2013

No description provided.

@zupo
Copy link

@zupo zupo commented Nov 26, 2013

Same here, build #1760932 on travis pro.

@Aaron1011
Copy link

@Aaron1011 Aaron1011 commented Nov 29, 2013

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

@zupo
Copy link

@zupo zupo commented Nov 30, 2013

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

@Aaron1011
Copy link

@Aaron1011 Aaron1011 commented Dec 23, 2013

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

@zupo
Copy link

@zupo zupo commented Dec 23, 2013

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

@Aaron1011
Copy link

@Aaron1011 Aaron1011 commented Dec 23, 2013

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

@roidrage
Copy link
Contributor

@roidrage roidrage commented Feb 26, 2014

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

@zupo
Copy link

@zupo zupo commented Feb 27, 2014

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

@zupo
Copy link

@zupo zupo commented Feb 27, 2014

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
Copy link

@roll roll commented Mar 2, 2014

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
Copy link

@roll roll commented Mar 2, 2014

$ 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
Copy link
Member Author

@rkh rkh commented Mar 2, 2014

That's a bug in travis-lint.

@roll
Copy link

@roll roll commented Mar 2, 2014

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
Copy link

@pezholio pezholio commented Mar 14, 2014

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
Copy link
Contributor

@roidrage roidrage commented Mar 14, 2014

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

eschwartz pushed a commit to aerisweather/aerisjs that referenced this issue Mar 14, 2014
Edan Schwartz
- NOTE: must set branch condition,
  but there is a bug in travis causing it not to
  work:
  travis-ci/travis-ci#1675
eschwartz pushed a commit to aerisweather/aerisjs that referenced this issue Mar 14, 2014
Edan Schwartz
- Travis deploy is not working
  see  travis-ci/travis-ci#1675
@roidrage
Copy link
Contributor

@roidrage roidrage commented Mar 17, 2014

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
Copy link

@Joshua-Anderson Joshua-Anderson commented Mar 20, 2014

@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
Copy link
Member Author

@rkh rkh commented Mar 20, 2014

@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
Copy link

@eschwartz eschwartz commented Mar 20, 2014

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
Copy link

@ryanbillingsley ryanbillingsley commented Mar 20, 2014

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

jaimegildesagredo added a commit to jaimegildesagredo/expects that referenced this issue Mar 22, 2014
More info here: travis-ci/travis-ci#1675
@scytacki
Copy link

@scytacki scytacki commented Mar 27, 2014

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

scurker added a commit to scurker/currency.js that referenced this issue Jan 30, 2015
anowell added a commit to anowell/servur that referenced this issue Feb 9, 2015
Workaround for:
  travis-ci/travis-ci#1675
@2m
Copy link

@2m 2m commented Feb 9, 2015

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

justnom added a commit to dynamo-media/grunt-magpie that referenced this issue Feb 10, 2015
@BanzaiMan
Copy link
Member

@BanzaiMan BanzaiMan commented Feb 11, 2015

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!

BanzaiMan added a commit to travis-ci/docs-travis-ci-com that referenced this issue Feb 11, 2015
travis-ci/travis-ci#1675 has been fixed,
so we need to document how this condition is expected to behave.
@2m
Copy link

@2m 2m commented Feb 12, 2015

Thanks. It works on my test repo.

@thedrow
Copy link

@thedrow thedrow commented Feb 12, 2015

I'm glad that this issue is finally resolved.

@skiwi2
Copy link

@skiwi2 skiwi2 commented Feb 12, 2015

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
Copy link
Member

@BanzaiMan BanzaiMan commented Feb 12, 2015

@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.

@BanzaiMan BanzaiMan closed this Feb 12, 2015
@atomicules
Copy link

@atomicules atomicules commented Feb 15, 2015

atomicules added a commit to simplenote-vim/simplenote.py that referenced this issue Feb 15, 2015
Hoping this is the fix based on this advice:
travis-ci/travis-ci#1675 (comment)

References #10
@atomicules
Copy link

@atomicules atomicules commented Feb 15, 2015

@BanzaiMan
Copy link
Member

@BanzaiMan BanzaiMan commented Feb 15, 2015

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

@atomicules
Copy link

@atomicules atomicules commented Feb 17, 2015

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

janraasch added a commit to janraasch/gulp-twitter that referenced this issue Feb 19, 2015
travis-ci/travis-ci#1675 was recently fixed
janraasch added a commit to janraasch/generator-gulpplugin-coffee that referenced this issue Feb 19, 2015
travis-ci/travis-ci#1675 has been fixed
@vaibhavsagar
Copy link

@vaibhavsagar vaibhavsagar commented Feb 25, 2015

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
Copy link

@atomicules atomicules commented Feb 25, 2015

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

@vaibhavsagar
Copy link

@vaibhavsagar vaibhavsagar commented Feb 25, 2015

That worked! Thanks so much @atomicules!

@chrisbaldauf
Copy link

@chrisbaldauf chrisbaldauf commented Jul 7, 2015

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.

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
Copy link
Member

@BanzaiMan BanzaiMan commented Jul 7, 2015

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

@travis-ci travis-ci locked and limited conversation to collaborators Jul 7, 2015
superbrothers added a commit to superbrothers/capturejs that referenced this issue Jul 26, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.