Dpl: script provider don't work with bundler on travis

[timoschilling]

I want to deploy with Capistrano after a Travis build.

I have tried some different thinks:
A. This results in a bundler: command not found: cap error

deploy:
  provider: script
  script: bundle exec cap integration deploy
  on:
    branch: master

B. This results in the same error on Travis but works on my local machine:

after_success: "[[ $TRAVIS_BRANCH = 'master' ]] && gem install dpl && dpl --provider=script --script='bundle exec cap integration deploy'"

C. This works

after_success: "[[ $TRAVIS_BRANCH = 'master' ]] && bundle exec cap integration deploy"

[BanzaiMan]

Below, I explain why these options behave the way they do. It does not present much in the way of the solution, however. In the end, then, at present, the option C is the best workaround.

dpl is executed with Ruby 1.9.3, which is pre-installed on all build images. The reason that A fails is, then, that the 1.9.3 installation with which dpl runs does not have the same gems as your build does. If you _are_ using Ruby 1.9.3, the issue becomes the same as B.

The problem with B is that, when dpl is executed this way, we are stashing away the local changes, including gems installed by Bundler previously during the build. Thus the gems installed are not visible to bundle in the --script argument. If you add --skip_cleanup, I believe cap will be found. This may not be what you want (because you _want_ to clean up), however.

I hope that makes sense.

[timoschilling]

Why _I want to clean up_?

[BanzaiMan]

Some git-based deployments (such as Heroku and OpenShift) do not work if the local git repo is not clean.

[timoschilling]

Ok, that's not a problem in my case. Why you don't run the deploy with the user selected ruby?

[BanzaiMan]

Because, at this time, it is the only one that is guaranteed to exist on all build images. We want to update it, of course, but that needs some work.

[ppires]

An update would be great, since capistrano is dropping support for ruby < 2.0!
https://github.com/capistrano/capistrano/commit/6015f943f4734c8744ff1534f9e455bb3f01b874

[BanzaiMan]

To think, it might be OK to switch to Ruby specified by $TRAVIS_RUBY_VERSION if this value is defined. The only worry right now is that the specs are failing for 2.3.x. (because json 1.8.1 cannot be compiled for it).

[nazarhussain]

Any update on this issue? I am still facing this issue.

Deploying application
bundler: command not found: cap

[jeffbyrnes]

Still an issue, by the way. Seems after_success is still the best workaround.

[nazarhussain]

Yes but its still a workaround

[ioquatix]

I ran into this issue too. I ended up using after_success:.

[BanzaiMan]

I believe this is now documented in https://docs.travis-ci.com/user/deployment/script/#Ruby-version.

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. 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

[ioquatix]

I believe this is still an issue Mrs stale Bot.

[wulab]

This works for me.

deploy:
  provider: script
    script: rvm use $(< .ruby-version) do bundle exec cap integration deploy
    skip_cleanup: true
    on:
      branch: master

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. 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

[ioquatix]

We moved to using build jobs, with a deploy job and an if: branch. It worked very well, better than deploy:. I think that's the way forward. I vote to close this issue.

[BanzaiMan]

Closing.