Image displaying the mascot of packagecloud and travis ci

Using Travis CI to publish your software or library packages to Packagecloud

Many companies implement a continuous integration (CI) strategy to deploy, build, test and release code incrementally. Once a release is ready, it will be tagged with a version and published to a repository where it can be easily installed with a few clicks by the user. There is no simpler and better repository than Packagecloud for 2 reasons:

  1. Packagecloud has integrations with many CI platforms with step-by-step instructions like this one for Travis CI
  2. Users can easy install those packages with Packagecloud’s install scripts, removing the need to understand the operating system where the package will be installed

To integrate your Travis CI workflow with Packagecloud, here are the steps:

    1. Create an account on Packagecloud, and then create a repository to store the software package that we build
    2. Create a Travis CI account by signing up via GitHub to enable access to your codebase
    3. Retrieve the Packagecloud API key and add/modify your Travis CI .travis.yml to contain instructions to build and publish the software package

Nomenclature

We use the word repository to refer to a code repository, e.g., GitHub, and also a package repository, e.g., Packagecloud.

We use the term package to refer to both software or programming libraries that maintainers/creators create for usage by others, with the subtle difference being the former refers to a piece of software that the end-user can use, e.g., a Slack desktop client, and the latter can be used as building blocks by developers to create software.

Create an account and repository on Packagecloud

You can create a new Packagecloud account here: https://packagecloud.io/users/new.

Once you’ve created an account, there is a simple wizard that will guide you through to create a repository to store your packages.

If you have already completed the wizard before and would like to create a new repository, login and go here: https://packagecloud.io

Click ‘Create a repository’
undefined

In the ‘Create a repository’ modal, fill in the details as follows:

undefined

Your Travis CI experience with Packagecloud

You could be in one of three situations here:

    • Situation 1: You already use TravisCI to continuously build & test your code so you already have the ‘.travis.yml’ build configuration file. You are looking to push your package to Packagecloud for distribution to your end-users.
    • Situation 2: You have a codebase that can only build a package. You are looking at setting up continuous integration with TravisCI to continuously build, test and push your package to Packagecloud for distribution to your end-users.
    • Situation 3: You don’t have a codebase to build a package but want to get an idea of what such a codebase and continuous integration with TravisCI and Packagecloud looks like.

Create or fork a codebase that creates a package

If you have no codebase (Situation 3), you can fork a Packagecloud GitHub code repository that we created to build an npm test package: https://github.com/computology/node-test-package/

Go to the repository and click ‘Fork’
undefined

Fork the repository to another GitHub account
undefined

Create an account with Travis CI

Here we will make an account with Travis CI by signing up with GitHub. This will allow for Travis CI to access the npm test package repository we forked in the previous subsection.

From the Travis CI documentation:

  1. Go to Travis-ci.com and Sign up with GitHub (or Bitbucket, Gitlab, Assembla if your codebase is hosted there).
  2. Accept the Authorization of Travis CI. You’ll be redirected to GitHub.
  3. Click on your profile picture in the top right of your Travis Dashboard, click Settings and then the green Activate button
    undefined
  4. Select the repositories you want to use with Travis CI. Or you click the Activate all repositories using GitHub Apps button on the getting started page to just activate all your repos.
    undefined
  5. You may need to select an appropriate Travis CI plan and follow the prompts to get started.

Add/Modify the .travis.yml build configuration file

Here is a sample config of how to integrate Travis CI into your codebase to build and publish your package to packagecloud.io.

Create a .travis.yml file

If needed, create a ‘.travis.yml’ file then add the following:

deploy:
  provider: packagecloud
  repository: YOUR REPO
  username: YOUR USERNAME
  token: YOUR TOKEN
  dist: YOUR DIST

  skip_cleanup: true

There are five important details you need to note in the `deploy` step:

  • `repository:` YOUR REPO
      • Name of the repository you created in your Packagecloud account
  • `username:` YOUR USERNAME
      • Your Packagecloud username
  • `token:` YOUR TOKEN
  • It is recommended to encrypt your API Token. Install the Travis CI command line client and run the following command in your project directory to insert the encrypted token to your .travis.yml:

travis encrypt THE-API-TOKEN --add deploy.token

  • `dist:` YOUR DIST
      • For Debian or RPM: an OS/dist supported by Packagecloud, like `ubuntu/bullseye` or `centos/5`
      • For npm: `node`
      • For python: `python`
      • For Java JAR, WAR, or AAR: `maven2`
      • For Ruby Gems: leave blank
  • `skip_cleanup: true`
    • Before the release, Travis CI will clean up any additional files and changes you made.
    • As you will generate an npm package that is intended to be released, you need to skip that cleanup.

Commit this .travis.yml file to your GitHub repository:

  1. `git add .travis.yml`
  2. `git commit -m “Add Travis CI build config file”`
  3. `git push origin master`

Example minimal configuration .travis.yml file

language: generic
script:
- npm pack
deploy:
  provider: packagecloud
  repository: repository
  username: username
  token:
    secure: <API-TOKEN-ENCRYPTED-BY-TRAVIS-CLI-TOOL>
  dist: node

  skip_cleanup: true

Here, the `language` is set as `generic`, which is an image containing essential CI tools, Python, databases and services, go, node_js, ruby, jvm, php. 

The `script` phase runs the build script: `npm pack`.

And after the npm package is built, the `deploy` phase provides all the configuration allowing Travis CI to push to your Packagecloud repository after a successful build.

Additional phases in the job lifecycle and deploy options

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.

Specifying the 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 the `build` directory of your project.

deploy:
  provider: packagecloud
  local-dir: build
  # ⋮

Alternatively, 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 its contents within the local-dir directory. Ensure the source package and its contents are output to the same directory for it to work.

Conditional releases

You can deploy only when certain conditions are met. The Travis CI documentation expands more on Conditional Releases with `on:`.

Running commands before and after release

Sometimes you want to run commands before or after releasing a package. You can use the `before_deploy` and `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

Confirm build passed

After making a push to trigger the Travis CI job lifecycle, you can review the build and deploy status by clicking on the build in the Travis CI Dashboard: https://app.travis-ci.com/dashboard
undefined

On Travis CI’s end in the virtual machine’s logs, we can see this build passed and the npm package was built and deployed to the repository in Packagecloud:
undefined

undefined

Confirm package push

Go to your Packagecloud repository with the url: https://packagecloud.io/<PACKAGECLOUD_USERNAME>/<PACKAGECLOUD_REPONAME>/

You should see your package that was built and pushed by Travis CI.
undefined



Now that was easy!

Hungry for more knowledge?

Related posts