Recently, I created an Angular App with current Angular CLI 1.0.0-rc.0 using Yarn instead of NPM. When I pushed some code to the GitHub repo and opened a pull request for my teammates to review, an information box popped up on GitHub suggesting to connect to a GitHub Integrations tool. Then with every push or pull request the app is built and tested by the integration tool, allowing for a quick feedback about whether it is safe to integrate the code. Let’s give it a try, I thought and decided to go with Travis CI. An hour later I had everything up and running. Here is what you need to do:
First of all, authorize Travis CI to access your GitHub repos and hook into push events. Thanks to GitHub Integrations this is done by the push of two buttons. Second, for Travis CI to build your app it looks for a .travis.yml configuration file in your application’s root folder. This is what it looks like:
| dist: trusty | |
| sudo: required | |
| language: node_js | |
| node_js: | |
| – “7” | |
| os: | |
| – linux | |
| env: | |
| global: | |
| – DBUS_SESSION_BUS_ADDRESS=/dev/null | |
| – DISPLAY=:99.0 | |
| – CHROME_BIN=chromium-browser | |
| before_script: | |
| – sh -e /etc/init.d/xvfb start | |
| install: | |
| – yarn | |
| script: | |
| – yarn run lint | |
| – yarn run test — –watch=false | |
| – yarn run pree2e | |
| – yarn run e2e | |
| cache: yarn |
travis.yml hosted with ❤ by GitHub
# .travis.yml
dist: trusty
sudo: required
language: node_js
node_js:
- "7"
os:
- linux
env:
global:
- DBUS_SESSION_BUS_ADDRESS=/dev/null
- DISPLAY=:99.0
- CHROME_BIN=chromium-browser
before_script:
- sh -e /etc/init.d/xvfb start
install:
- yarn
script:
- yarn run lint
- yarn run test -- --watch=false
- yarn run pree2e
- yarn run e2e
cache: yarnTravis CI starts up a virtualization environment that will execute your build scripts. Stick with the defaults and select an Ubuntu Trusty on Linux with sudo permissions. Configure the environment to use Node.js and set the required version to at least version 6. I required version 7 because I remembered we had problems with Node.js 6 in a different Angular project. But for a newly created Angular CLI project version 6 should be fine as well.
Now, before running the build scripts a couple of environment variables have to be set. This is to allow running tests that require a graphical user interface, in our case for Karma and Protractor to run their tests in Google Chrome. The xvfb command will launch an X-Server with a virtual display.
As I said earlier, this Travis CI configuration is for Angular CLI projects using the Yarn package manager in favor of NPM. As you might know, Yarn enables us to lock down the project dependencies in a lock file named yarn.lock which mitigates the risk of indeterminate dependency versions on different systems. Travis CI comes with Yarn support and will install Yarn automatically if the project contains both a package.json and a yarn.lock file. To fetch all dependencies add a yarn install command to the Travis CI configuration. You can even omit install as this is the default command in Yarn. To speed up builds, the Yarn cache can be saved across builds. See the cache: yarn property at the bottom of the config file.
Then add build scripts for linting, Karma tests and Protractor e2e tests. Make sure to disable the watch mode in Karma by adding -- --watch=false, otherwise the tests won’t finish and the build will be stuck forever.
The Protractor e2e tests are likely to fail because Protractor tries to update the webdriver before execution. While this works with NPM it is different with Yarn as it can’t load the webdriver from a deep link. This is a known issue in Angular CLI that is supposed to be fixed soon. For the time being, disable the webdriver update adding --no-webdriver-update to the e2e script. Then add a preceding script to update the webdriver before test execution. As this is not a Travis CI related problem, I put these modifications in package.json instead of .travis.yml.
That’s all, you’re done! Push your code to GitHub and watch Travis CI build your app. As a bonus you can display the build status as a badge on your GitHub page or README file. See this basic project on GitHub and the CI build for reference. Feel free to contact me for any questions.
This post was written by:
