Specifying Node version
You can adjust the Node version that your project uses to build by specifying the version number in your
.travis.yml configuration file.
The virtual machine that Travis spins up then uses NVM to run your build on multiple versions. Using the keyword stable runs the latest safe version, which I find useful.
# .travis.yml language: node_js node_js: - 'stable' - '0.12'
Bear in mind that adding multiple versions will increase your time as the build process runs on all of them — but it’s nice to be able to specify which version in case you do need more than one environment.
One of the first things that automatically happens on your build server with a Node project is
npm install to get dependencies from NPM.
We recently started caching the
node_modules directory on the VM to speed up installation, and therefore the build.
# .travis.yml cache: directories: — bower_components — node_modules — path/to/any/directory
A useful tip is to cache this directory and
bower_components, or any other 3rd-party installed dependencies you have in your project.
Git checkout depth
Another optimisation is adjusting the git checkout depth in your config file. This means that the build server will check out only the latest commit(s) from your git repository.
I can’t think of a situation I’ve had yet that requires more than the very latest commit to build, so it’s worth doing this even if it only speeds up a little bit!
# .travis.yml git: depth: 1
Whitelisting the branches you want to build, or blacklisting the ones you don’t can be quite a useful feature.
I sometimes use blacklisting — the except parameter — to make sure that I’m not building every single test branch that I create. You can also use RegEx for this in your
.travis.yml as shown below (eg: matching
Using only allows you to do the inverse and whitelist branches, if you desire.
# .travis.yml branches: except: — /^test-.*$/ only: — master — develop
Post deploy tasks
I use NPM’s built-in hook
post_deploy to run checks on my personal website after a deployment to AWS. This is very useful for me as one of the tasks performed checks for 404s using grunt-check-pages. Implementing this is as easy as adding your script/task name to .travis.yml as shown below:
# .travis.yml after_deploy: — grunt post_deploy