This page documents deployments using dpl v1 which currently is the default version. The next major version dpl v2 will be released soon, and we recommend starting to use it. Please see our blog post for details. dpl v2 documentation can be found here.
Travis CI can automatically push your RPM, Deb, Deb source, or RubyGem package build artifacts to packagecloud.io after a successful build.
For a minimal configuration, all you need to do is add the following to your
deploy: provider: packagecloud repository: "YOUR REPO" username: "YOUR USERNAME" token: "YOUR TOKEN" dist: "YOUR DIST" # like 'ubuntu/precise', or 'centos/5', if pushing deb or rpms
Take note that your repository name should not have a forward slash in it. For example if your repository appears as
username / repo on packagecloud.io, you should only put
repo in the
repository: option and put
username in the
You can retrieve your api token by logging in and visiting the API Token page under Account Settings.
This is the list of supported distributions for the ‘dist’ option.
It is recommended to encrypt your auth token. Assuming you have the Travis CI command line client installed, you can do it like this:
travis encrypt THE-API-TOKEN --add deploy.token
You can also have the
travis tool set up everything for you:
travis setup packagecloud
Keep in mind that the above command has to run in your project directory, so it can modify the
.travis.yml for you.
Branch to release from #
You can explicitly specify the branch to release from with the on option:
deploy: provider: packagecloud on: branch: production # ⋮
Alternatively, you can also configure Travis CI to release from all branches:
deploy: provider: packagecloud on: all_branches: true # ⋮
By default, Travis CI will only release from the master branch.
Builds triggered from Pull Requests will never trigger a release.
Releasing build artifacts #
After your tests ran and before the release, Travis CI will clean up any additional files and changes you made.
Maybe that is not what you want, as you might generate some artifacts that are supposed to be released, too. There is now an option to skip the clean up:
deploy: provider: packagecloud skip_cleanup: true # ⋮
Specify package folder #
By default, the packagecloud provider will scan the current directory and push all supported packages.
You can specify which directory to scan from with the
local-dir option. This example scans from
build directory of your project.
deploy: provider: packagecloud local-dir: build # ⋮
Alternately, you may wish to specify the
package_glob argument to restrict which files to scan. It defaults to
**/* (recursively finding all package files) but this may pick up other artifacts you don’t want to release. For example, if you only want to push gems in the top level directory:
deploy: provider: packagecloud package_glob: "*.gem" # ⋮
A note about Debian source packages #
If the packagecloud provider finds any
.dsc files, it will scan it and try to locate it’s contents within
local-dir directory. Ensure the source package and it’s contents are output to the same directory for it to work.
Conditional releases #
You can deploy only when certain conditions are met.
See Conditional Releases with
Running commands before and after release #
Sometimes you want to run commands before or after releasing a package. You can use the
after_deploy stages for this. These will only be triggered if Travis CI is actually pushing a release.
before_deploy: "echo 'ready?'" deploy: # ⋮ after_deploy: - ./after_deploy_1.sh - ./after_deploy_2.sh