Automating Javascript Testing, Deploy with npm & Travis CI to Github (part 3)

December 11, 2015

Not long ago, I wrote about my experience and setup of Travis CI for running javascript testing (on an angular based web application) on my open source project, Echoes Player. On last week, I completed my setup with an auto deployment - in which I share the solution that worked for me.

Initial Setup

Echoes Player is a pure web ui application for playing and managing media from youtube. The backend for this app is youtube’s data api. The current version of Echoes is wrapped with angularjs.

It is developed with bdd in mind, using jasmine.js as a testing framework in order to write tests, spy on functions and setup expectations.

To run the tests, I use karma test runner - which orchestrates the environment setup to run the tests.

When the project is developed or run in Travis, I use Phantomjs as the javascript engine to run the tests on. Karma also preprocesses some source files in order to compile code from es2015 to es5, convert templates to compiled templates (optimisation for angular) and more.

CI with Travis

Up until a week ago, I used Travis as a second protection for running javascript unit tests. Travis is a cloud service for continuos integration and deploy. Those javascript unit tests ran on each commit and pull request that was pushed to echoes repository. In Travis I also successfully integrated browserstack, in order to run e2e tests of the new repository version on a selected remote group of browsers.

With this setup, whenever there were errors in tests or in build, I was informed by email to the right spot. It is very powerful workflow.

Release with npm

Echoes Player is deployed to github pages (remember - it’s a ui based app), so, all I had to do is push a new version of bundled code to gh-pages branch of my repository.

The preparation for release involves several steps to take before pushing to github the new code. For that, I’m using npm’s scripts feature - I defined a custom script - “release” - script that will run the required operations before i can commit to github.

"scripts": {
    "test": "gulp test && protractor ./gulp/config/",
    "release": "gulp dist:prepare && gulp build && gulp style && gulp assets && gulp dist && gulp dist:rev"

Automating Deployment to Github with Travis

The new addition to echoes ci scripts added automatic deployment to github after a successful unit tests session. Adding this step was a bit of challenge, after reading a few articles things still didn’t work as expected. Only after experimenting with my own configuration and understanding, I finally completed the ci flow to be complete with Travis.

I took the approach of pushing a new version of code to gh-pages while not keeping the history. This approach simply worked after many other tries.

The steps for adding Auto Deployment in Travis

First, create a new github token for travis and generate an encrypted travis key (there’s also an npm package for generating Travis tokens with node).

Then, I added the secured key to the yml file - Usually, the token generation process will prompt to add the new key to your project’s yml file.

finally, add this after_success step:

- git config --global ""
- git config --global "travis-ci"
- npm run release
- cd dist
- git init
- git add .
- git commit -m "deployed new version from travis"
- git push --force --quiet "https://${GH_TOKEN}@${GH_REF}" master:gh-pages > /dev/null 2>&1

few notes on the after_success flow:

First, I setup my username email of github in travis virtual machine.

Second, I’m using ”npm run release” script that I defined. Eventually, this script created a “dist” directory, which includes a bundled minified version of the app (ready to deploy).

Finally, the process shifts to the dist directory, creates a new git repository, add & commit the files to the local repository and with the new secured github token, push this directory contents to echoes repository (and also overrides the history for this branch).

A Note about not keeping the history:

I tried several commands for checking out the actual gh-pages of echoes in order to keep the history, but have come to a dead end each time. I do see a reason to keep history of production version with some strategy (release tags, commit messaged or other) so I’m still investigating this.

Final Notes

Adding that after_success step to the ci workflow has pushes echoes project to a full e2e ci & cd workflow using cloud services only (github, travis and browserstack). Now, I can be sure that a production version has been deployed automatically any time after whole of the tests passed.


My Consulting Packages

My consulting offerings include: Front End Development, Code reviews (React, Redux, Typescript, Javascript, Angular, NgRx), workshops, Consulting and Development. Feel free to reach out thru the below forms or through thecontact page.

© 2022, Built with Gatsby, follow me at: