on: tags condition for deploys still not working #1675

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

Comments

Projects
None yet
@rkh
Member

rkh commented Nov 26, 2013

No description provided.

@zupo

This comment has been minimized.

Show comment
Hide comment
@zupo

zupo Nov 26, 2013

Same here, build #1760932 on travis pro.

zupo commented Nov 26, 2013

Same here, build #1760932 on travis pro.

@Aaron1011

This comment has been minimized.

Show comment
Hide comment
@Aaron1011

Aaron1011 Nov 29, 2013

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

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

@zupo

This comment has been minimized.

Show comment
Hide comment
@zupo

zupo Nov 30, 2013

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

zupo commented Nov 30, 2013

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

@Aaron1011

This comment has been minimized.

Show comment
Hide comment
@Aaron1011

Aaron1011 Dec 23, 2013

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

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

@zupo

This comment has been minimized.

Show comment
Hide comment
@zupo

zupo Dec 23, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@Aaron1011

Aaron1011 Dec 23, 2013

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

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

@roidrage

This comment has been minimized.

Show comment
Hide comment
@roidrage

roidrage Feb 26, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@zupo

zupo Feb 27, 2014

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

zupo commented Feb 27, 2014

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

@zupo

This comment has been minimized.

Show comment
Hide comment
@zupo

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

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

This comment has been minimized.

Show comment
Hide comment
@roll

roll 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 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

This comment has been minimized.

Show comment
Hide comment
@roll

roll 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>'

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

This comment has been minimized.

Show comment
Hide comment
@rkh

rkh Mar 2, 2014

Member

That's a bug in travis-lint.

Member

rkh commented Mar 2, 2014

That's a bug in travis-lint.

@roll

This comment has been minimized.

Show comment
Hide comment
@roll

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

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

This comment has been minimized.

Show comment
Hide comment
@pezholio

pezholio 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

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

This comment has been minimized.

Show comment
Hide comment
@roidrage

roidrage Mar 14, 2014

Member

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

Member

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 added a commit to aerisweather/aerisjs that referenced this issue Mar 14, 2014

dply travis
- NOTE: must set branch condition,
  but there is a bug in travis causing it not to
  work:
  travis-ci/travis-ci#1675

eschwartz added a commit to aerisweather/aerisjs that referenced this issue Mar 14, 2014

Remove Travis deploy config
- Travis deploy is not working
  see  travis-ci/travis-ci#1675
@roidrage

This comment has been minimized.

Show comment
Hide comment
@roidrage

roidrage Mar 17, 2014

Member

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.

Member

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.

@BanzaiMan BanzaiMan referenced this issue in travis-ci/dpl Mar 18, 2014

Closed

PyPi deployment not working #109

@Joshua-Anderson

This comment has been minimized.

Show comment
Hide comment
@Joshua-Anderson

Joshua-Anderson Mar 20, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@rkh

rkh Mar 20, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@eschwartz

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

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

This comment has been minimized.

Show comment
Hide comment
@ryanbillingsley

ryanbillingsley Mar 20, 2014

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

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

@scytacki

This comment has been minimized.

Show comment
Hide comment
@scytacki

scytacki 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

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

@rkh

This comment has been minimized.

Show comment
Hide comment
@rkh

rkh Mar 31, 2014

Member

@scytacki thanks, that actually looks really good

Member

rkh commented Mar 31, 2014

@scytacki thanks, that actually looks really good

@roll

This comment has been minimized.

Show comment
Hide comment
@roll

roll Apr 28, 2014

A little strange way that works for me with basic "on" config:

deploy:
  ...
  on:
    tags: true
$ git commit -m 'Travis, do it'
$ git tag version
$ git push --tags
$ git push #build deploys

PS.

deploy:
  ...
  on:
    tags: true
    all_branches: true

Works without multiple deployments.
But with order git push --tags, git push there are two deployments on the same commit.

roll commented Apr 28, 2014

A little strange way that works for me with basic "on" config:

deploy:
  ...
  on:
    tags: true
$ git commit -m 'Travis, do it'
$ git tag version
$ git push --tags
$ git push #build deploys

PS.

deploy:
  ...
  on:
    tags: true
    all_branches: true

Works without multiple deployments.
But with order git push --tags, git push there are two deployments on the same commit.

petecheslock added a commit to petecheslock/berks2env that referenced this issue Apr 29, 2014

DennisAlund pushed a commit to DennisAlund/sonosjs that referenced this issue May 6, 2014

Dennis Alund
Updating travis configuration
Trying to get auto deployment to work as mentioned in travis-ci/travis-ci#1675

pussinboots added a commit to pussinboots/playzanox that referenced this issue May 6, 2014

thedrow referenced this issue in jpellerin/nose2 May 8, 2014

@rkh

This comment has been minimized.

Show comment
Hide comment
@rkh

rkh May 13, 2014

Member

We updated how we expose tags, didn't that fix the issue?

Member

rkh commented May 13, 2014

We updated how we expose tags, didn't that fix the issue?

@roidrage

This comment has been minimized.

Show comment
Hide comment
@roidrage

roidrage May 13, 2014

Member

We're exposing the $TRAVIS_TAG variable, but haven't changed anything beyond that.

Member

roidrage commented May 13, 2014

We're exposing the $TRAVIS_TAG variable, but haven't changed anything beyond that.

@skiwi2

This comment has been minimized.

Show comment
Hide comment
@skiwi2

skiwi2 Jan 7, 2015

Any news on this?

skiwi2 commented Jan 7, 2015

Any news on this?

mikebryant added a commit to mikebryant/django-autoconfig that referenced this issue Jan 7, 2015

outsideris added a commit to summernote/angular-summernote that referenced this issue Jan 9, 2015

outsideris added a commit to summernote/angular-summernote that referenced this issue Jan 9, 2015

outsideris added a commit to summernote/angular-summernote that referenced this issue Jan 9, 2015

@BanzaiMan BanzaiMan referenced this issue in travis-ci/dpl Jan 13, 2015

Closed

npm deploy only master branch #214

@atomicules atomicules referenced this issue in mrtazz/simplenote.py Jan 15, 2015

Closed

hook up travis ci to deploy to pypi from git tags #10

cburgmer added a commit to cburgmer/inlineresources that referenced this issue Jan 15, 2015

@djindjic

This comment has been minimized.

Show comment
Hide comment
@djindjic

djindjic Jan 16, 2015

It would be worth to support deployment of tagged builds on selected branch(es) instead of trigger it on for every (unsafe) branch which could be tagged accidentally of maliciously.

It would be worth to support deployment of tagged builds on selected branch(es) instead of trigger it on for every (unsafe) branch which could be tagged accidentally of maliciously.

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

@2m

This comment has been minimized.

Show comment
Hide comment
@2m

2m Feb 9, 2015

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

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

@2m 2m referenced this issue in 2m/test-pypi-deploy Feb 9, 2015

Open

Remove all_branches: True from .travis.yaml #1

justnom added a commit to dynamo-media/grunt-magpie that referenced this issue Feb 10, 2015

@keithamus keithamus referenced this issue in chaijs/chai Feb 11, 2015

Merged

Fix travis.yml deploy #365

@BanzaiMan

This comment has been minimized.

Show comment
Hide comment
@BanzaiMan

BanzaiMan Feb 11, 2015

Member

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!

Member

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

Documnt `tags` condition correctly
travis-ci/travis-ci#1675 has been fixed,
so we need to document how this condition is expected to behave.
@2m

This comment has been minimized.

Show comment
Hide comment
@2m

2m Feb 12, 2015

Thanks. It works on my test repo.

2m commented Feb 12, 2015

Thanks. It works on my test repo.

@thedrow

This comment has been minimized.

Show comment
Hide comment
@thedrow

thedrow Feb 12, 2015

I'm glad that this issue is finally resolved.

thedrow commented Feb 12, 2015

I'm glad that this issue is finally resolved.

@skiwi2

This comment has been minimized.

Show comment
Hide comment
@skiwi2

skiwi2 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)

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

This comment has been minimized.

Show comment
Hide comment
@BanzaiMan

BanzaiMan Feb 12, 2015

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@atomicules

atomicules Feb 15, 2015

atomicules added a commit to mrtazz/simplenote.py that referenced this issue Feb 15, 2015

Changes to .travis.yml hopefully to fix deploy
Hoping this is the fix based on this advice:
travis-ci/travis-ci#1675 (comment)

References #10
@atomicules

This comment has been minimized.

Show comment
Hide comment
@atomicules

atomicules Feb 15, 2015

@BanzaiMan

This comment has been minimized.

Show comment
Hide comment
@BanzaiMan

BanzaiMan Feb 15, 2015

Member

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

Member

BanzaiMan commented Feb 15, 2015

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

@atomicules

This comment has been minimized.

Show comment
Hide comment
@atomicules

atomicules Feb 17, 2015

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

@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

janraasch added a commit to janraasch/generator-gulpplugin-coffee that referenced this issue Feb 19, 2015

@vaibhavsagar

This comment has been minimized.

Show comment
Hide comment
@vaibhavsagar

vaibhavsagar 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?

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

This comment has been minimized.

Show comment
Hide comment
@atomicules

atomicules Feb 25, 2015

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

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

@vaibhavsagar

This comment has been minimized.

Show comment
Hide comment
@vaibhavsagar

vaibhavsagar Feb 25, 2015

That worked! Thanks so much @atomicules!

That worked! Thanks so much @atomicules!

@dentarg dentarg referenced this issue in twingly/twingly-search-api-ruby Apr 24, 2015

Closed

Release gem to rubygems.org #10

@chrisbaldauf

This comment has been minimized.

Show comment
Hide comment
@chrisbaldauf

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

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

This comment has been minimized.

Show comment
Hide comment
@BanzaiMan

BanzaiMan Jul 7, 2015

Member

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

Member

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.