Continuous testing and deployment of Polymer elements using Wercker

3 min readJun 9, 2015

At Google I/O 2015, Polymer 1.0 was announced as “production ready.” With 1.0 they introduced huge performance improvements and new elements to be used. The Polymer ecosystem now seems prepared for development.

As a Polymer fan, of course I wanted to create Polymer elements and actually did some. For a published component, I needed automated testing and documentation published on the web. Thankfully, the Polymer team had published seed-element as a boilerplate, which included:

Testing by the web-component-tester
Documentation by the <iron-component-page> element

With those tools at hand, I wanted continuous delivery of the element, i.e. every time I push the code to GitHub, tests are run and, the documentation page is updated if the test passes, and it should happen automatically. There are many CI-as-a-Service to achieve this today. This time I chose Wercker, which had support for Docker images and I know had push-to-github-pages deployment step.

Testing

web-component-tester requires “real” browsers such as Chrome or Firefox to be running for testing. For most CI services normally do not support testing under GUI, you will need to set up xvfb environment (cf. on Travis).

I have made a simple Docker image for running wct, named motemen/nodejs-java-browsers. It is based on motemen/xvfb-chrome-firefox, which contains (obviously from its name) xvfb, chrome and firefox for headless browsing.

With this image, you can run wct like below:

npm install
./node_modules/bower/bin/bower install --allow-root --config.interactive=false
xvfb-run ./node_modules/web-component-tester/bin/wct

As a totally different option, you may use Sauce Labs for remote Selenium.

Deployment

Although iron-component-page serves nifty documentation pages, deploying index.html of seed-element has some awkwardness.

With it, we have to provide the page under a directory of /components/element-name/, as a sibling of its dependencies (the “components” part may differ), which means that as GitHub Pages they have to be served at https://user.github.io/my-element/components/my-element/. Not a cool URL. The official gp.sh places index.html as a redirection to /components/my-element/. I did not like that, so instead I placed one <base> tag to avoid redirection.

<!DOCTYPE html>
<html>
<head>
  <base href='components/asciidoctor-element/'> <!-- This line! -->
  <script src="../webcomponentsjs/webcomponents-lite.js"></script>
  <link rel="import" href="../iron-component-page/iron-component-page.html">

With this, you can serve the documentation page at https://user.github.io/my-element/.

Below is the script, which creates a directory with such index.html to be pushed as gh-pages branch.

A working wercker.yml

Wercker’s new “Ewok” stack is based on Docker. So the image mentioned above can be used to run tests for Polymer elements. Also, I published the script to generate Polymer documents as a wercker step: motemen/polymer-element-build-docs.

Thus you can configure your wercker project with wercker.yml configured like blow:

box: motemen/nodejs-java-browsers
build:
  steps:
    — npm-install
    — script:
        name: bower install
        code: |
          ./node_modules/bower/bin/bower install --allow-root --config.interactive=false
    — script:
        name: npm test
        code: |
          xvfb-run npm test
deploy:
  steps:
    — motemen/polymer-element-build-docs
    — lukevivier/gh-pages:
        token: $GITHUB_TOKEN
        basedir: docs

A live example of wercker application is asciidoctor-element, which is hosted on GitHub, tested on Wercker and deployed to GitHub Pages. Check it out there.

Continuous testing and deployment of Polymer elements using Wercker

Testing

Deployment

A working wercker.yml

Written by motemen