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.