Deploying gem under different platforms (Ruby and Java)

Deployment
1

Hi,

We build two versions of our gem. One for Ruby and one for JRuby . This is achieved by running gem build ./yourgem.gemspec under each platform as in the example below:

$ rvm use ruby
$ gem build ./yourgem.gemspec # this creates file gooddata-2.0.0.gem
$ rvm use jruby
$ rm Gemfile.lock
$ bundle install
$ gem build ./yourgem.gemspec # creates gooddata-2.0.0-java.gem

I can do the same in the script section in my .travis.yml but it doesn’t work using DPL. I’ve tried the following:

- stage: gem-release
  rvm:
    - 2.3
    - jruby-9.1.14
  deploy:
    provider: rubygems
    api_key: $RUBYGEMS_API_KEY

The JRuby deploy job behaves as if it was run under Ruby. Is it possible to deploy a gem under different platforms using DPL?

Thanks.

1 Like
2

You can’t use an array for the rvm value (which would have otherwise defined a build matrix at the top level) inside the job definition in jobs.include. https://github.com/panjan/gooddata-ruby/blob/08054e92ce7c02ebf92768bd9aafd50fb5418e16/.travis.yml#L194-L196 To ensure that a job is properly defined, we pick the first value. This is hinted at (but not exactly explicitly stated in https://docs.travis-ci.com/user/build-stages/#build-stages-and-build-matrix-expansion).

To achieve your goal, define 2 jobs, one with rvm: 2.3 and another with rvm: jruby-* (your choice), and have them each push a gem it builds (remember that the jobs in a build matrix do not have shared storage, so even if you build the gems in previous stages, they will not be available to your deployment stage jobs).

3

Thank you for the quick reply @BanzaiMan. I’ve tried splitting the deploy part into two separate jobs. https://travis-ci.org/panjan/gooddata-ruby/jobs/495077726

  - stage: gem-release
    name: deploy MRI gem
    rvm: 2.3
    deploy:
      provider: rubygems
      gem: gooddata
      api_key: $RUBYGEMS_API_KEY
  - stage: gem-release
    name: deploy JRuby gem
    rvm: jruby-9.1.14
    deploy:
      provider: rubygems
      gem: gooddata
      api_key: $RUBYGEMS_API_KEY

It’s still building the Ruby version even with rvm: jruby-*. Did I miss anything?

4

You have a wrong job name defined in https://github.com/panjan/gooddata-ruby/blob/ac0fbc50aaba83c42224e792e20bbff536c7b003/.travis.yml#L201. You see that the correct Ruby is used https://travis-ci.org/panjan/gooddata-ruby/jobs/495077726#L506.

5

JRuby indeed appears in the log but the output is a Ruby gem.

Successfully built RubyGem
  Name: gooddata
  Version: 2.0.0
  File: gooddata-2.0.0.gem

My deploy script produces gooddata-2.0.0-java.gem both in Travis and locally.

6

I’m sorry to say, but that’s what your Rake task is doing.

I don’t know why it works on your machine, but I can tell you that you are responsible for this portion of the build.

(I should note that you are running the release task in the script phase of your build, which is semantically speaking misleading.)

We can enable the debug feature for this repo if you would like to gain live access to the VM.

7

I believe we use the same command to build the gem as travis-ci/dpl. That is gem build ./path-to-gemspec. If the command was really run under the Java platform, RubyGems would build the file gooddata-2.0.0-java.gem (with -java).

Please be so kind and enable the debug feature. I’ll be happy to investigate this further and submit a PR if needed.

8

My guess is that your gem … is using CRuby instead of JRuby.

At any rate, the debug feature has been enabled on the repository. Be sure to read https://docs.travis-ci.com/user/running-build-in-debug-mode/#restarting-a-job-in-debug-mode-via-api.

Thanks.

9

@BanzaiMan, thank you for enabling the debugging feature. I can now confirm that dpl is run under CRuby. The command is rvm $(travis_internal_ruby) do... where travis_internal_ruby is 2.4.1 (CRuby). We can see how the command is composed here. I believe that leaving out the rvm do part would have the desired result. I.e. Ruby gems would be deployed under the platform specified in the rvm section, not only under CRuby.

Do you want to fix this? If you confirm my idea, I will be happy to submit a PR.

10

This is a tough situation, to be completely upfront about it.

We invoke deployment via rvm $(travis_internal_ruby) … because we know ahead of time this Ruby is capable of invoking dpl and deploying build artifacts. The current ruby set in rvm: key may or may not be. Hence the dilemma.

If you are confident that your Ruby (whatever it is) is capable of executing dpl, you could try redefining the travis_internal_ruby function. Without testing at all, I would first try with:

function travis_internal_ruby() {
  echo "$TRAVIS_RUBY_VERSION"
}
11

Thanks for the explanation @BanzaiMan. I completely understand the difficulties of supporting different rubies. It’s probably not worth it in this case. I’ll try the suggested workaround.