Travis

RubyGems Deployment

This page documents deployments using the next major version dpl v2, which currently is in a beta release phase. Please see our blog post for details. The current default version is dpl v1. Check dpl v1 documentation here.

Be sure to read the v2 deployment overview.

Travis CI can automatically release your Ruby gem to RubyGems after a successful build.

For a minimal configuration, add the following to your .travis.yml:

deploy:
  provider: rubygems
  api_key: <encrypted api_key>
  edge: true # opt in to dpl v2

Alternatively, you can use username and password:

deploy:
  provider: rubygems
  username: <username>
  password: <encrypted password>

Status #

Support for deployments to Rubygems is *stable**.

Known options #

Use the following options to further configure the deployment. Either api_key or username and password are required.

api_key Rubygems api key — secret, type: string
username Rubygems user name — type: string, alias: user
password Rubygems password — secret, type: string
gem Name of the gem to release — type: string, default: repo name
gemspec Gemspec file to use to build the gem — type: string
gemspec_glob Glob pattern to search for gemspec files when multiple gems are generated in the repository (overrides the gemspec option) — type: string
host type: string

Shared options #

cleanup Clean up build artifacts from the Git working directory before the deployment — type: boolean
run Commands to execute after the deployment finished successfully — type: string or array of strings

Environment variables #

All options can be given as environment variables if prefixed with RUBYGEMS_.

For example, api_key can be given as RUBYGEMS_API_KEY=<api_key>.

Securing secrets #

Secret option values should be given as either encrypted strings in your build configuration (.travis.yml file) or environment variables in your repository settings.

Environment variables can be set on the settings page of your repository, or using travis env set:

travis env set RUBYGEMS_API_KEY <api_key>

In order to encrypt option values when adding them to your .travis.yml file use travis encrypt:

travis encrypt <api_key>

Or use --add to directly add it to your .travis.yml file. Note that this command has to be run in your repository’s root directory:

travis encrypt --add deploy.api_key <api_key>

You can retrieve your api key by following these instructions.

Pre-releasing #

Instead of releasing for each new version of your gem, you can create a prerelease for each build.

This gives your gem’s users the option to download a newer, possibly more unstable version of your gem. To enable this, add the following line to your gemspec, underneath your existing version line:

s.version = "#{s.version}-alpha-#{ENV['TRAVIS_BUILD_NUMBER']}" if ENV['TRAVIS']

If your gem’s current version is 1.0.0, the prerelease version will be 1.0.0-alpha-20, where 20 is the build number.

Specifying the gem name #

By default, we will try to release a gem by the same name as the repository name.

You can explicitly set the name via the gem option:

deploy:
  provider: rubygems
  # ⋮
  gem: <name>

In order to release gems based on the current branch use separate deploy configurations:

deploy:
  - provider: rubygems
    # ⋮
    gem: <name-1>
    on:
      branch: master
  - provider: rubygems
    # ⋮
    gem: <name-2>
    on:
      branch: staging

Or using YAML references:

deploy:
  - &deploy
    provider: rubygems
    # ⋮
    gem: <name-1>
    on:
      branch: master
  - <<: *deploy
    gem: <name-2>
    on:
      branch: staging

Specifying the gemspec #

You can specify the gemspec with the gemspec option:

deploy:
  provider: rubygems
  # ⋮
  gemspec: <gemspec>

Deploying tags #

Most likely, you would only want to deploy when a new version of your package is cut.

To do this, you can include a tags condition like so:

deploy:
  provider: rubygems
  # ⋮
  on:
    tags: true

If you tag a commit locally, remember to run git push --tags to ensure that your tags are uploaded to GitHub.

Pull Requests #

Note that pull request builds skip the deployment step altogether.

See also #