Huon on the internet

Travis on the train, part 2

By Huon Wilson01 May 2015

After announcing travis-cargo a few days ago in Helping Travis catch the rustc train, I got some great hints/contributions from Jan Segre and had a fun little time automating code coverage collection via Unfortunately, this is a breaking change for existing users of travis-cargo, but the migration is easy.

(If you’re wondering what travis-cargo is, see the linked post.)

Version 0.1 of travis-cargo is now available on PyPI0 and should be installed via that medium. This works on Travis:

pip install 'travis-cargo<0.2' --user && export PATH=$HOME/.local/bin:$PATH

The explicit <0.2 requirement will reduce the risk of builds breaking due to upstream changes in future, as I will make every effort to follow semantic versioning and bump versions for any further breaking changes.


Part of migrating to PyPI requires renaming the script to and making it no longer a directly-executable script. This means that a direct git clone and alias as I suggested previously will not work.

From now, the only supported way to install travis-cargo is via pip as demonstrated above, and the recommended format to use with pip is the PyPI package, with a version requirement. The example installation listed above will install a travis-cargo binary to ~/.local/bin and then ensure that that it is available to the shell by name.

However, that’s not the only breaking change: the cargo subcommand has been removed since the default binary is now much longer, and looks more like the real cargo program. Cargo subcommands passed to travis-cargo directly work as one would expect. Migration:

# before
./tc cargo build
# after
travis-cargo build

The doc-upload subcommand and the --only and -q arguments have not been changed.

I’ve opened pull requests on all users of travis-cargo that I found via Github’s search. I apologise if I missed you, fortunately the migration is straight-forward.

Covering your coverage needs

The new and improved travis-cargo includes travis-cargo coveralls, which will use the awesome kcov along with Rust’s debuginfo support to record the test coverage of your libraries, and then upload them to

order-stat’s test coverage: being a little library makes it easy to get high numbers.

kcov combines with Coveralls to make supporting this ridiculously easy: simply register/activate and add sudo: required & travis-cargo coveralls to your .travis.yml. (The sudo requirement is necessary to install kcov; it unfortunately makes Travis much slower to start builds.)

travis-cargo coveralls should successfully handle both in-crate and external tests, so the Coveralls dashboard will display the total coverage across all real tests (doc-tests are figments of our imaginations). At the moment, Cargo doesn’t provide reliable programmatic access to everything it knows, so travis-cargo coveralls first searches the output of cargo test for the binaries it runs, and then executes those binaries under kcov. For this to work best, the test profile must have debug = true (which is the default).

Travis-cargo by example: the sequel

order-stat’s .travis.yml now looks like (diff for the change):

language: rust
sudo: required

  - nightly
  - beta
  - pip install 'travis-cargo<0.2' --user && export PATH=$HOME/.local/bin:$PATH
  - |
      travis-cargo build &&
      travis-cargo test &&
      travis-cargo bench &&
      travis-cargo doc
  - travis-cargo --only beta doc-upload
  - travis-cargo coveralls

# ...

travis-cargo’s README contains more information.

(Thanks to Simon Kågström for assistance with getting kcov working properly, lifthrasiir and jscheivink for their tutorials on collecting coverage, and Jan Segre for the assistance with packaging and feedback.)

  1. Incidentally, I found publishing Python packages on PyPI much more difficult than publishing Rust packages on Great job on getting cargo and so streamlined, Alex Crichton, Yehuda Katz and everyone who has contributed!