-
Configure your build to match your production environment. Set up the language you use, and the services, databases and tools that you normally use.
-
Set up Notifications 🔔 → Fix broken builds as soon as possible. Ensure that you're always developing on a known stable branch.
-
Setting up a deployment pipeline 🚀 Check out Build Stages
Some workflows tips and tricks!
-
Build Pull Requests 💪
-
Automatically Cancel pull request builds waiting to start.
-
Protect your default (main/master?) branch in GitHub, to ensure your tests run before the pull requested is merged.
There's more information available at: https://help.github.com/articles/enabling-required-status-checks/
You can fork any of the 
repositories below, go to your profile page, activate it, start committing to GitHub and see your Travis builds running.
-
Using Build Stages in both an Ember Application running in a Crystal Server:
-
Cron jobs - scheduling builds
📖 You can find information and examples in our Build Stages Docs.
This example tests a Rust binary on multiple targeted platforms using Docker, and if the tests pass, release it to GitHub Releases. Demo credit goes to the fantastic @joecorcoran - thank you!
-
.travis.ymlfile used:language: rust services: docker branches: only: - master # Install tools for running tests install: - cargo install cross # Setup jobs per platform jobs: include: # 64-bit tests - &test stage: test script: cross test --target $TARGET env: TARGET=x86_64-unknown-linux-gnu # 32-bit tests - <<: *test env: TARGET=i686-unknown-linux-gnu # 64-bit release - &deploy stage: deploy env: TARGET=x86_64-unknown-linux-gnu script: skip before_deploy: - cross build --release --target $TARGET - cp target/$TARGET/release/travis-docker-demo . - tar czf travis-docker-demo-$TARGET-$TRAVIS_BUILD_NUMBER.tar.gz travis-docker-demo - TRAVIS_TAG=build-$TRAVIS_BUILD_NUMBER deploy: api_key: secure: "..." file: travis-docker-demo-$TARGET-$TRAVIS_BUILD_NUMBER.tar.gz provider: releases skip_cleanup: true # 32-bit release - <<: *deploy env: TARGET=i686-unknown-linux-gnu
Credit goes to the amazing @lislis, thank you!
An Ember application built on the top of the pizza server.
.travis.yml file used
language: node_js
node_js:
- '6'
- '7'
sudo: false
cache:
directories:
- "$HOME/.npm"
before_install:
- npm config set spin false
- npm install -g phantomjs-prebuilt ember-cli
- phantomjs --version
install:
- npm install
jobs:
include:
- stage: test
script: ember test
- stage: build
script: ember build
- stage: deploy
deploy: &heroku
provider: heroku
app: quattro-stagione
script: skip
on:
branch: master
api_key:
secure:
...
Crystal lang, deployed to NPM.
- https://github.com/lislis/pizza-server
- https://travis-ci.org/lislis/pizza-server
- https://www.npmjs.com/package/berlin-pizza
.travis.yml file used
language: crystal
jobs:
include:
- stage: build
script: crystal build --release src/pizza-server.cr
- stage: deploy
script: skip
deploy: &heroku
provider: heroku
app: berlin-pizza
api_key: $HEROKU_AUTH_TOKEN
on:
branch: master
- stage: npm publish
script: skip
deploy:
provider: npm
api_key: $NPM_API_KEY
email: $EMAIL
on:
branch: master
tags: true
The most popular HTML, CSS, and JavaScript framework for developing responsive, mobile first projects on the web.
This demonstrates a conditional build stage: browser tests using Sauce Labs that only run on push builds because pull request builds don’t have access to credentials.
stages:
- test
- name: browser
if: type = push
| Pull request build | Push build |
|---|---|
 |
 |
Quasar Analytics is a general-purpose compiler for translating data processing and analytics over semi-structured data into efficient plans that run 100% in the target infrastructure.
stages:
- name: clean
if: NOT type = pull_request
- name: compile
- name: unit test
- name: test
- name: publish
# weirdly, we have to add the extra PR check
if: NOT type = pull_request
…
jobs:
include:
- stage: clean
env:
script: ./sbt -DisIsolatedEnv=${ISOLATED_ENV:=false} clean
- stage: compile
env:
script:
- set -e
- |-
./sbt -DisIsolatedEnv=${ISOLATED_ENV:=false} ++$TRAVIS_SCALA_VERSION \
checkHeaders \
test:compile
- set +e
# note that the "test" stage has special significance to Travis (it's the only matrix-able stage)
- stage: unit test
env:
script:
- |-
./sbt -DisIsolatedEnv=${ISOLATED_ENV:=false} ++$TRAVIS_SCALA_VERSION \
it/sideEffectTestFSConfig \
"testOnly -- xonly" \
"exclusive:testOnly -- xonly"
- stage: publish
env:
script:
- set -e
- './sbt ++$TRAVIS_SCALA_VERSION doc web/assembly'
- scripts/testJar
# release to sonatype
- scripts/quasarPublishAndTag
# release to github
- scripts/publishJar
- set +e
| Failing build | Passing build |
|---|---|
 |
 |
| One of the jobs in the test stage fails, so the final stage doesn’t run. | All the jobs in the test stage pass, so the final stage runs. |
-
See its build status clicking at
You can schedule builds in Travis CI:
Demo credit goes to the wonderful @aakritigupta, thank you!
Play, test, build, deploy!
📖 Learn some more in our documentation: Travis CI Docs
📰 Don't miss any new features, checkout the Travis CI Blog
Questions? Drop us a line at [email protected]
