New publication workflow at W3C β€” main component
HTML JavaScript Other
Latest commit 9fe3e60 Feb 6, 2017 @tripu tripu committed on GitHub Merge pull request #395 from w3c/greenkeeper-morgan-1.8.0
Update morgan to version 1.8.0 πŸš€
Failed to load latest commit information.
lib wrong metadata name passed to the job publisher Dec 12, 2016
.gitignore Exclude JSDoc output from version control Aug 7, 2015
.jshintignore JSHint exclusions more fine-grained; lines sorted. May 18, 2015
.travis.yml API_KEY: use env var if available Jun 14, 2016
config.js.example Introducing a new endpoint for tar upload that requires ldap authenti… Mar 4, 2016
package.json Merge pull request #395 from w3c/greenkeeper-morgan-1.8.0 Feb 6, 2017 include decision and request id in the notification email Dec 21, 2016

Build Status Coverage Status Dependency Status devDependency Status Inline docs


Echidna is the central piece of software taking care of the new publication workflow at W3C. The plan is for Echidna and related sub-projects (see below) to automate the publication of new specs under

Using Echidna as an editor

If you are a spec editor, you do not need to install Echidna, nor to run it locally.

Please see the wiki for how to use Echidna as a spec editor.

Hacking Echidna as a developer


To run Echidna, you need to install Node.js first. This will install npm at the same time, which is required as well.

Then run the following commands with your favorite terminal:

git clone
cd echidna
cp config.js.example config.js
npm install

Running it locally

Note: local setup of the full system is not supported currently due to dependency on W3C's DB and IPP system, but having mock services that emulate these pieces is our short-term goal.

In your terminal, run the following:


You may use the optional defined below:

  1. STAGING_PATH: path in the local filesystem where documents will be downloaded; staged. (Default /var/www/html/trstaging/.)
  2. HTTP_LOCATION: HTTP endpoint for Specberus and the Third Party Resources Checker. (Default http://localhost/trstaging/.)
  3. PORT: where Echidna will be listening for publication requests. (Default 3000.)
  4. RESULT_PATH: local path where Echidna will dump the results of publication requests in JSON format.

Alternatively, you can use the configuration file config.js.

Once the server is started, you can throw publication requests at it through a curl/POST request to its enpoint, http://localhost:3000/api, or using the web-based testbed (described below).

Testing Echidna

This section describes how to run Echidna's test suite to make sure that the project itself is working properly over time. Note that the test suite is not intended to test actual documents.

Running the unit test suite

You can run the test suite with the following command line:

npm test

Using test documents

For testing purposes, we are using a local web server. The test server simulates some of the W3C services, such as the CSS and HTML validators, or the token authorization checker. It also serves a set of sample drafts.

You can launch this test server separately by using:

npm run testserver

When the test server is running, the testbed with all drafts will be available in http://localhost:3001.

Feedback and contributions

Please refer to our contribution reference to learn how to contact us, give feedback, or actively contribute to this project.