on: tags condition for deploys still not working #1675

rkh · Nov 26, 2013

No description provided.

Same here, build #1760932 on travis pro.

zupo · Nov 26, 2013

Same here, build #1760932 on travis pro.

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

Aaron1011 · Nov 29, 2013

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

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

zupo · Nov 30, 2013

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

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

Aaron1011 · Dec 23, 2013

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

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

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.

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

Aaron1011 · Dec 23, 2013

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

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

roidrage · Feb 26, 2014

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

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

zupo · Feb 27, 2014

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

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

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

$ 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 · 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>'

That's a bug in travis-lint.

rkh · Mar 2, 2014

That's a bug in travis-lint.

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

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

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

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

roidrage · 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.

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.

roidrage · 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.

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

Joshua-Anderson · 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.

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

rkh · 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?

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.

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.

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

ryanbillingsley · Mar 20, 2014

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

@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

Joshua-Anderson · Mar 21, 2014

@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

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

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

@scytacki thanks, that actually looks really good

rkh · Mar 31, 2014

@scytacki thanks, that actually looks really good

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

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

rkh · May 13, 2014

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

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

roidrage · May 13, 2014

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

Any news on this?

skiwi2 · Jan 7, 2015

Any news on this?

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.

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.

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

2m · Feb 9, 2015

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

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 · 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!

Thanks. It works on my test repo.

2m · Feb 12, 2015

Thanks. It works on my test repo.

I'm glad that this issue is finally resolved.

thedrow · Feb 12, 2015

I'm glad that this issue is finally resolved.

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

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

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?

atomicules · Feb 15, 2015

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?

@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

BanzaiMan · Feb 15, 2015

@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

@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=""

atomicules · Feb 15, 2015

@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=""

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

BanzaiMan · Feb 15, 2015

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

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

atomicules · Feb 17, 2015

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

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?

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?

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

atomicules · Feb 25, 2015

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

That worked! Thanks so much @atomicules!

vaibhavsagar · Feb 25, 2015

That worked! Thanks so much @atomicules!

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.

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.

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

BanzaiMan · Jul 7, 2015

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

rkh referenced this issue Nov 26, 2013
Closed
Expose the tag for the commit currently built #1674

BanzaiMan referenced this issue Dec 25, 2013
Closed
TRAVIS_BRANCH env variable contains tag name for builds triggered by a tag #1670

BanzaiMan referenced this issue Mar 2, 2014
Closed
on tags:true does not appear to be working for node project. #1876

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

5328695

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

c79c4fb

Joshua-Anderson referenced this issue Mar 16, 2014
Closed
GitHub Releases Deployment #1648

BanzaiMan referenced this issue in travis-ci/dpl Mar 18, 2014
Closed
PyPi deployment not working #109

jaimegildesagredo added a commit to jaimegildesagredo/expects that referenced this issue Mar 22, 2014

Temporal fix for travis deploy
More info here: travis-ci/travis-ci#1675

e66b38d

colinmacdonald referenced this issue in goinstant/goangular Apr 1, 2014
Merged
chore(deploy): travis deploy #86

nfriedly referenced this issue Apr 10, 2014
Closed
Problem with deploy as an array form #2020

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

Fix to get around travis-ci bug
travis-ci/travis-ci#1675

397d510

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

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

e7725c2

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

deploy is not triggerd
travis-ci/travis-ci#1675

6b9c34c

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

Add travis->pypi config (Fixes #128)

b9c2a5e

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

all_branches: true. See travis-ci/travis-ci#1675.

a2c2bbf

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

enable release in travis-ci
It's known issue, refer <travis-ci/travis-ci#1675>

ded1083

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

enable release in travis-ci
It's known issue, refer <travis-ci/travis-ci#1675>

52e57f2

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

enable release in travis-ci
It's known issue, refer <travis-ci/travis-ci#1675> and <travis-ci/travis-ci#2498>

08777a7

cburgmer added a commit to cburgmer/csscritic that referenced this issue Jan 11, 2015

Remove branches declaration for travis in the hope of working around t…
…ravis-ci/travis-ci#1675

2144b0b

BanzaiMan referenced this issue in travis-ci/dpl Jan 13, 2015
Closed
npm deploy only master branch #214

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

Bump version & try to work around travis-ci/travis-ci#1675

1692f62

dtinth added a commit to bemusic/bms-js that referenced this issue Jan 17, 2015

fix(travis): set all_branches: true to workaround travis-ci/travis-ci…
…#1675

0c6016e

scurker added a commit to scurker/currency.js that referenced this issue Jan 30, 2015

Work around of travis-ci/travis-ci#1675

2e1f77a

anowell added a commit to anowell/servur that referenced this issue Feb 9, 2015

Fix and version bump for Travis
Workaround for: travis-ci/travis-ci#1675

9919cb2

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

Fixing known Travis CI bug.
URL: travis-ci/travis-ci#1675

9adebc5

keithamus referenced this issue in chaijs/chai Feb 11, 2015
Merged
Fix travis.yml deploy #365

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.

41f22d0

BanzaiMan closed this Feb 12, 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

c338302

janraasch added a commit to janraasch/gulp-twitter that referenced this issue Feb 19, 2015

chore(travis): remove work-around
travis-ci/travis-ci#1675 was recently fixed

9bf5b8a

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

chore(travis): remove work-around
travis-ci/travis-ci#1675 has been fixed

e2f908b

dentarg referenced this issue in twingly/twingly-search-api-ruby Apr 24, 2015
Closed
Release gem to rubygems.org #10

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

chore(travis.yml): release on all branches
travis-ci/travis-ci#1675

498b582

travis-ci/travis-ci

Join GitHub today

on: tags condition for deploys still not working #1675

Comments

rkh commented Nov 26, 2013

rkh referenced this issue Nov 26, 2013

This comment has been minimized.

zupo commented Nov 26, 2013

This comment has been minimized.

Aaron1011 commented Nov 29, 2013

This comment has been minimized.

zupo commented Nov 30, 2013

This comment has been minimized.

Aaron1011 commented Dec 23, 2013

This comment has been minimized.

zupo commented Dec 23, 2013

This comment has been minimized.

Aaron1011 commented Dec 23, 2013

BanzaiMan referenced this issue Dec 25, 2013

This comment has been minimized.

roidrage commented Feb 26, 2014

This comment has been minimized.

zupo commented Feb 27, 2014

This comment has been minimized.

zupo commented Feb 27, 2014

BanzaiMan referenced this issue Mar 2, 2014

This comment has been minimized.

roll commented Mar 2, 2014

This comment has been minimized.

roll commented Mar 2, 2014

This comment has been minimized.

rkh commented Mar 2, 2014

This comment has been minimized.

roll commented Mar 2, 2014

This comment has been minimized.

pezholio commented Mar 14, 2014

This comment has been minimized.

roidrage commented Mar 14, 2014

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

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

Joshua-Anderson referenced this issue Mar 16, 2014

This comment has been minimized.

roidrage commented Mar 17, 2014

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

This comment has been minimized.

Joshua-Anderson commented Mar 20, 2014

This comment has been minimized.

rkh commented Mar 20, 2014

This comment has been minimized.

eschwartz commented Mar 20, 2014

This comment has been minimized.

ryanbillingsley commented Mar 20, 2014

This comment has been minimized.

Joshua-Anderson commented Mar 21, 2014

jaimegildesagredo added a commit to jaimegildesagredo/expects that referenced this issue Mar 22, 2014

This comment has been minimized.

scytacki commented Mar 27, 2014

This comment has been minimized.

rkh commented Mar 31, 2014

colinmacdonald referenced this issue in goinstant/goangular Apr 1, 2014

nfriedly referenced this issue Apr 10, 2014

This comment has been minimized.

roll commented Apr 28, 2014

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

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

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

This comment has been minimized.

rkh commented May 13, 2014

This comment has been minimized.

roidrage commented May 13, 2014

This comment has been minimized.

skiwi2 commented Jan 7, 2015

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

cburgmer added a commit to cburgmer/csscritic that referenced this issue Jan 11, 2015

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

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