Clean, Working Jenkins Tests for Polymer Elements

I wound up yesterday thinking that the only way to run Karma tests under Jenkins on my Linode was to upgrade from Debian 6 to Debian 7. So that is what I do.

This is more work than I am inclined to do for a CI server—especially when there are so many good CI services to be purchased. But, then again, it never hurts to keep things up-to-date. The instructions for upgrading Debian 6 to 7 from Linode work quite nicely, thank you very much.

Once I have that installed, making it through the last step of the Jenkins/Karma/Polymer test setup—installing Chrome—is easy enough:

$ sudo dpkg -i ~/Downloads/google-chrome-stable_current_i386.deb
Selecting previously unselected package google-chrome-stable.
(Reading database ... 55887 files and directories currently installed.)
Unpacking google-chrome-stable (from .../google-chrome-stable_current_i386.deb) ...
dpkg: dependency problems prevent configuration of google-chrome-stable:
 google-chrome-stable depends on libappindicator1; however:
  Package libappindicator1 is not installed.

Well, of course I needed one last yak. But, after installing that missing dependency (first correcting the broken Chrome install):

$ sudo apt-get -f install
$ sudo apt-get install libappindicator1

I can now get Chrome installed:

$ sudo dpkg -i ~/Downloads/google-chrome-stable_current_i386.deb
(Reading database ... 57351 files and directories currently installed.)
Preparing to replace google-chrome-stable 37.0.2062.120-1 (using .../google-chrome-stable_current_i386.deb) ...
Unpacking replacement google-chrome-stable ...
Setting up google-chrome-stable (37.0.2062.120-1) ...
Processing triggers for man-db 

Yay!

More importantly, I finally have a passing Jenkins build:



No really, it is passing:



And it is reproduceable as well, which is always a bonus. Actually, that is kind of a must for CI.

I am not quite done, however. My eee-polymer-tests package, which provides reasonable default NPM dependencies for testing Polymer elements (Karma, Jasmine, Bower, etc) also generates skeleton test code. If run with no arguments, as is done with a NPM install from a CI server, eee-polymer-tests code will query the developer for the name of the element being tested. In fact, it is doing so in my Karma run:

> eee-polymer-tests@0.0.1 postinstall /var/lib/jenkins/jobs/Patterns in Polymer/workspace/book/code-js/parent_child/node_modules/eee-polymer-tests
> ./generator.js

What is the name of the Polymer element being tested? 
eee-polymer-tests@0.0.1 node_modules/eee-polymer-tests
├── colors@0.6.2
├── minimist@1.1.0
└── bower@1.3.9

The readline module that is doing this seems to know that this is being run in a non-interactive process—it does not wait for an answer nor does it run any of the code that would generate testing code after an answer.

Still, I would like to save it the trouble (and myself some concern). The way to accomplish this seems to be via the tty module in Node. With it, I can interrogate a file descriptor like STDIN to see if it is associated with a terminal:

var fs = require('fs');
var readline = require('readline');
var tty = require('tty');

if (element) {
  generate();
}
else if (tty.isatty(process.stdin)) {
  queryForElementName();
}
else {
  console.log('Nothing to generate.');
}

In this case, if STDIN is not a TTY, then it is not coming from an interactive session and I do nothing. All that needs to happen is to install the normal Karma, Bower, etc. dependencies.

That works just fine:

> eee-polymer-tests@0.0.1 postinstall /var/lib/jenkins/jobs/Patterns in Polymer/workspace/book/code-js/parent_child/node_modules/eee-polymer-tests
> ./generator.js

Nothing to generate.
eee-polymer-tests@0.0.1 node_modules/eee-polymer-tests
├── colors@0.6.2
├── minimist@1.1.0
└── bower@1.3.9 

I may still have a problem on my hand. Readers of the book that I am testing here, Patterns in Polymer, might want to run the tests themselves. But if they try to npm install like my test code is doing, they will be prompted for an element because they will be running the command in an interactive shell.

Looks like I am going to need a lockfile mechanism of some sort for this. Tomorrow.

Day #179

‹prev | My Chain | next›