Parsoid/Jenkins

How our Jenkins testing works.

Scenario 0: One patch submitted for review by a wikimedia.org address

This is probably the most common scenario.

1. A job will be launched that lints the JavaScript. We'll report that it's broken, but it won't cause a negative review.
2. Another job will check that the patch can be merged with origin/master. This may cause a negative review from jenkins-bot.
3. The final job will check that parserTests has no new failures after this patch. This won't cause a negative review, but may in the future.

Watch the jenkins reports that come in for patches, as the latter two reports are very important to the review process.

Scenario 1: Multiple patches submitted by a wikimedia.org address

Less common, but possible.

1. Jobs 1 and 2 from scenario 0 will still fire as normal.
2. Another job is launched, for each patch, that checks the parserTests value for HEAD against the parserTests value for HEAD~1 (i.e. the commit right before HEAD). This should catch any regressions caused by this patch.

As ever, the only failable offense is a non-mergeable patch. But watch the parserTests results anyway, as they'll be important.

Scenario 2: A patch (or patches) submitted by non-WMF address

1. Jobs 1 and 2 from scenario 0 are launched, no problem
2. Job 3 is not launched because it involves running our code on the server without any security checks. A WMF employee can trigger the tests by reviewing the patch positively.

Dependencies

JS dependencies are pulled from a contrib repository:

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Parsoid/js/contrib parsoid-js-contrib

To update, copy the current package.json into the contrib repository and run npm install. Then commit all files and push for review.