(First of all install Travis CLI if you haven’t done it yet.)

Tip 1: Updating GitHub Project Pages Automatically after Building

Important note! There’s a much easier way of doing virtually the same thing explained here. The only difference is that GithHub Pages will only be updated if the build is green when following the instructions bellow, as opposed to updating Pages as soon as something is pushed to the branch master. 

It’s pretty nice and very rare to have documentation up-to-date with the code base. Using Yatspec, GitHub and Travis CI (all part of my current work environment), it’s easy to test, document and publish the documentation automatically after a build (like this and this), and keep the docs always in synch with the code.

Let’s Do It…

1) (Obviously) Have Some Content to Publish

As mentioned before, the content I’m interested in publishing is the specification generated by Yatspec based on acceptance tests.

2) Configure GitHub Project Pages

Assuming the project is in a GitHub repository, just follow these instructions if it doesn’t have Pages configured yet.

3) Config Var GH_TOKEN

This token will allow a third-party app to push to your repository. To generate one, on GitHub, go to Settings -> Personal Access Token, then click on Generate New Token. You can review your tokens on your personal settings.

Travis CLI will encrypt the token and update travis.yml  for you (since –add option is being used) when typing:

travis encrypt GH_TOKEN={your.token} --add

4) Script update-gh-pages.sh

The script will use GH_TOKEN to deal with the gh-pages branch in your GitHub repository (adapt it as required).


if [ "$TRAVIS_PULL_REQUEST" == "false" ]; then
echo -e "Starting to update gh-pages\n"

#copy data we're interested in to other place
cp -R /tmp $HOME/spec

#go to home and setup git
cd $HOME
git config --global user.email "travis@travis-ci.org"
git config --global user.name "Travis"

#using token clone gh-pages branch
git clone --quiet --branch=gh-pages https://${GH_TOKEN}@github.com/rafaelfiume/Salume.git  gh-pages > /dev/null

#go into directory and copy data we're interested in to that directory
cd gh-pages
cp -Rf $HOME/spec/index.html index.html
cp -Rf $HOME/spec/* .

#add, commit and push files
git add -f .
git commit -m "Travis build $TRAVIS_BUILD_NUMBER pushed to gh-pages"
git push -fq origin gh-pages > /dev/null

echo -e "Done copying the spec\n"

4) Configure Travis CI to “Publish” in GitHub Project Pages

Tell Travis to run the script configuring the travis.yml.

- if [ "$TRAVIS_BRANCH" == "master" ]; then chmod 755 ./update-gh-pages.sh; ./update-gh-pages.sh; fi

After a successful build, the script will only run if checking into master. That makes sense, since the project docs must be updated and public available only if the app is being released in production (hence the master branch).

Again, you may want to adapt this config as necessary.

(Main source of this tip, including the update-gh-pages script, is here.)

Tip 2: Triggering Travis CI Builds from Other Buildings

Sometimes it’s necessary to have a build triggered by another build, and there’s no direct way of doing that with Travis CI.

In my case, I need to run end-to-end tests once Travis finishes building and deploying apps in the staging environment (more on that here if you’re interested). In other words, this project triggers an integration test in another build.

Here’s How To Do It…

In a few words, we configure the build (the trigger) to invoke Travis API to restart the build we want to be triggered.

1) Config Var ACCESS_TOKEN

Provide the ACCESS_TOKEN to Travis CI as an encrypted environment variable.

Find out your token with the following commands:

travis login
travis token

Provide the ACCESS_TOKEN to Travis CI as an encrypted environment variable (more about encrypted vars here).

travis encrypt ACCESS_TOKEN={your.token} --add

It will encrypt the token and update travis.yml for you thanks to the –add parameter.

2) Script trigger-build.sh

Use a script to invoke Travis API to trigger the build (adapt as you see fit). That’s why the ACCESS_TOKEN is necessary: Travis API requires it.


echo -e "Triggering Build...\n"

# Get last child project build number
BUILD_NUM=$(curl -s 'https://api.travis-ci.org/repos/rafaelfiume/Rainbow/builds' | grep -o '^\[{"id":[0-9]*,' | grep -o '[0-9]' | tr -d '\n')

echo -e "Build number is $BUILD_NUM\n"

# Restart last child project build
curl -i \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Authorization: token $ACCESS_TOKEN" \

3) Finish Changing travis.yml

Configure Travis CI to execute the trigger-build.sh script.

- if [ "$TRAVIS_BRANCH" == "staging" ]; then chmod 755 ./trigger-rainbow.sh; ./trigger-rainbow.sh; fi

(Main source of this tip, including the trigger-build script, is here.)

Tip 3: Using a Database on Heroku to Run Acceptance Tests During The Build

There are projects that use some sort of in-memory database on at least most of their acceptance tests, and the reason for that is to make them build faster.

I have a different point-of-view, and agree more with Dev/Prod parity. There will always be exceptions, but in most cases I prefer to use the same database (e.g. PostgreSQL) in production, staging and dev (including when writing acceptance tests as well).

Specially if you’re using Heroku to host your projects, it’s easy to create a database there, and pass an environment variable to Travis CI pointing to that database.

1) Create a Database on Heroku…

… which can be done using the Heroku CLI or the dashboard.

2) Use DATABASE_URL Config Var in Your App

If you application is deployed into Heroku, it’s already using DATABASE_URL environment variable to store the location of the database.

3) Config DATABASE_URL on Travis CI

Find out the database url using the command line or the dashboard. Since Travis will connect remotely to the db, append the following to the connection URL:


If you don’t want to expose the URL in the build logs, encrypt the variables as we did with the GH_TOKEN and ACCESS_TOKEN:

travis encrypt DATABASE_URL={database.url}?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory --add

Note: when using the command line, percent-encode the ‘&’ (%26) in the query parameter .

2 thoughts on “Travis CI Tips

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s