Travis CI and AppVeyor template to test your Rust crate on 5 architectures and publish binary releases of it for Linux, macOS and Windows
CI test your crate (library or binary) on Linux, macOS and Windows and on more than just the x86 architecture.
Cargo artifacts are cached and reused between CI builds.
"Deploys": Publish binary releases of your application by just pushing a new (Git) tag.
ci directory, and the
appveyor.yml files into the
repository where you host your Rust crate.
You'll have to adjust those files to meet your needs. Just look inside those
files for comments that start with the word
TODO; they'll tell you want needs
to be changed.
This is an overview of what must / can be changed:
The GitHub token used for deploys.
The list of test targets. Trim it down to reduce test times.
The Rust channel used for testing / deploys.
The "test phase". Tweak how your crate is tested.
the "package phase". Tweak what goes into the release tarball / zipfile.
You only need to push an annotated tag to kick off the build process.
# Optional: Publish a new version of your crate to crates.io $ cargo publish $ git tag -a $TAG $ git push origin $TAG
script that you can use to quickly install a binary release produced using this
$ curl -LSfs https://japaric.github.io/trust/install.sh | \ sh -s -- --git japaric/cross
For more details about this installation script see
If you don't want to generate binary releases at all, perhaps because your Cargo
project is a library or you only want to test your project, then you can simply
appveyor.yml, to always be false. For example:
# .travis.yml deploy: on: condition: $DEPLOY = never
First, figure out which version of the trust template you are using. The version
is written in the header of the
appveyor.yml files. If
there's no header, that means you are using version
Next, look at the change log to check if there's a new release and to learn, at a high level, how the template has changed: what has been fixed, what has been added, etc.
If it makes sense for you to upgrade, you can see the required "code" changes by looking at the "diff" between the version you are using and the version you are going to upgrade to. For example:
As for the upgrade itself, GitHub can generate a patch from the above diff that
then you can apply to your repository with
git am or similar:
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.