RubyGems Deployment
This page documents deployments using the dpl v2. Please see our blog post for details. You can check previous dpl v1 documentation here.
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.