JavaScript Continuous Integration with TravisCI


Last time we talked about automating JavaScript testing with Grunt.js, and even though we quite exhausted the topic, there is one thing left. The provided solution worked well for a solo developer or maybe a small team, however imagine you work with dozen developers, where everyone pushes one's commits constantly. Forcing all of them to follow a procedure of running automated script upon each commit, will be no trifle. Continuous integration comes to rescue. What it does is running predefined build scripts, in our case Grunt.js, on each predefined event - usually on each push.

TravisCI


As usual, we'll start a new topic with the easiest implementation to get you started with the technology. Once you master the basics, we'll continue with more advanced tools in the next article. Today we'll talk about TravisCI and create continuous integration for our last article code and only focus on needed changes. I've copied the code into new Git repository.

TravisCI integrates seamlessly with public and private GitHub repositories. Public ones are free of charge. To get you started, go to TravisCI site, connect with GitHub account and enable the toggle next your repository - that's it! Then we need to configure our repository to play together with the integration server.

Karma and TravisCI


TravisCI only supports Firefox based UI testing, so in order make things work, we need to align both karma.conf.js and karma.conf.require.js Karma configs using process.env.TRAVIS parameter, which notifies us whether we run the tests on Travis machine or not. We'll test our code on Chrome in development environment and on Firefox on integration one
browsers: process.env.TRAVIS ? ['Firefox'] : ['Chrome']
Since there is no actual screen to display the UI, Xvfb is used instead. However you'll need to tell your testing tool process about the display port, so it knows where to start Firefox. All this along with other configurations is stated in .travis.yml file. Before our testing scripts are run, we set the display to 99th configured screen and start xvfb process. 
before_script:
  - export DISPLAY=:99.0
  - sh -e /etc/init.d/xvfb start

TravisCI configuration


Let's look into our .travis.yml configuration file line by line: 
language: node_js
node_js:
  - 0.10

before_script:
  - export DISPLAY=:99.0
  - sh -e /etc/init.d/xvfb start
  - npm install
  - npm install -g bower
  - bower install

script:
  - grunt
TravisCI supports many languages, we of course interested in Node.js, which is configured in first line. Following the language declaration, we configure the versions of our distribution in lines 2 and 3. Later we define everything, that needs to be done prior to running the scripts.

Since each time we run the integration process on a blank machine, we should install all the packages listed in our package.json and bower.json files. To do so we first run the npm install command and after that both install bower globally and run the bower install directive. Lastly we specify the script command needed to be run, in our case simply grunt, as we want to run all the tasks defined in gruntfile.js file.

Package integration


Lastly, we need to add command name needed for running the tests in package.json.
"scripts": {
    "test": "grunt"
  }

Build status image


Once everything is configured, wouldn't it be cool to show the build status somewhere on team's dashboard or repository readme file. TravisCI provides a simple image, visualizing the status of last build. Just enter repository configuration page and click on the image to the right. Popup will be opened with image URL: 
https://travis-ci.org/aie0/jsdeepdive-javascript-continuous-integration-with-
travisci.svg?branch=master
Putting it in readme is one step task, just copy-paste the following line, substituting TRAVISCI_STATUS_IMAGE_URL with status image and TRAVISCI_REPOSITORY_PAGE with TravisCI repository page. 
[![Build Status](TRAVISCI_STATUS_IMAGE_URL)](TRAVISCI_REPOSITORY_PAGE)
In our case: 
[![Build Status](https://travis-ci.org/aie0/jsdeepdive-javascript-continuous-
integration-with-travisci.svg?branch=master)](https://travis-ci.org/aie0/jsdeepdive-
javascript-continuous-integration-with-travisci)
Hope you enjoyed the article, cause next time we'll be talking about JenkinsCI, which can be configured with any repository.

Comments

Post a Comment

Popular posts from this blog

CAP Theorem and blockchain

Image
In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store (such as a blockchain network) to simultaneously provide more than two out of the three guarantees: Consistency, Availability & Partition tolerance. CAP Theorem – the parts C: Consistency – At any given time, all nodes in the network have exactly the same (most recent) value. A: Availability – Every request to the network receives a response, though without any guarantee that returned data is the most recent. P: Partition tolerance – The network continues to operate, even if an arbitrary number of nodes are failing. Due to the nature of distributed data stores (such as blockchain), Partition tolerance is a given fact; there will always be failing/unreachable nodes in the network (not least because of the unstable nature of the internet). CAP Theorem states that one has to choose between C (Consistency) or A (Availability) when in the presence of P (Partition): Av...
Read more

Length extension attack

Image
What is length extension? When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Quick sidebar, before you freak out: Since HMAC does not use this construction, HMAC hashes are not prone to length extension attacks. So, a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. Algorithms like MD5, SHA-1 and most of SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack. Truncated versions of SHA-2, including SHA-384 and SHA-512/256 are not susceptible, nor is the SHA-3 algorithm. A bit more details ...
Read more

Contract upgrade anti-patterns

Image
A popular trend in smart contract design is to promote the development of upgradable contracts . To be fair, existing techniques to upgrade contracts have flaws, increase the complexity of the contract significantly, and ultimately introduce bugs - even in the Zeppelin contract upgrade strategy. In this article, we are going to detail our analysis of existing smart contract upgrade strategies, describe the weaknesses we have observed in practice, and provide recommendations for contracts that require upgrades. In a follow-up blog post, we will detail a method, contract migration, that achieves the same benefits with few of the downsides. An overview of upgradable contracts Two ‘families’ of patterns have emerged for upgradable smart contracts: Data separation, where logic and data are kept in separate contracts. The logic contract owns and calls the data contract. Delegatecall-based proxies, where logic and data are kept in separate contracts, also, but the data contr...
Read more