The Jenkins build output viewer seems to have broken recently. Specifically, it appears to be creating console sections start and end tags in a way that makes the output unbalanced HTML.
Problem
The actual console output from the plain text (with limited codes). This plain text undergoes three transformations, and somewhere along the way things are seemingly done based on raw HTML instead of based on safe text:
- The output is HTML escaped to display in a <pre> tag. This is the default Jenkins behaviour.
- ANSI escape codes are interpreted by the "AnsiColor" plugin for Jenkins. It interprets the "start" and "end" markers in a way that is similar to what xterm would do, and creates a <span> for the wrapped text with a similar CSS text color as what xterm would have displayed the text as.
- The "Console Section" plugin for Jenkins is running regular expressions from the Jenkins Configuration page and adding a <div> before any line that matches the "start" pattern, and adding a </div> after any line that matches the "end" pattern.
What's happening is that this opening <div> ends up not in front of the line, but inside an HTML comment that the AnsiColor plugin leaves behind.
As such:
[32m INFO [0m :quibble.commands:PHPUnit unit tests … [32m INFO [0m :quibble.commands:PHPUnit done
Becomes:
<!--<div class="section" data-level=""><div class="collapseHeader">PHPUnit unit tests<div class="collapseAction"><p onClick="doToggle(this)">Hide Details</p></div></div><div class="expanded"> [32m--><span style="color: #00CD00;">INFO<!--[0m--></span>:quibble.commands:PHPUnit unit tests … <!--[32m--><span style="color: #00CD00;">INFO<!--[0m--></span>:quibble.commands:PHPUnit done </div>
Whereas it used to be:
<div class="section" data-level=""><div class="collapseHeader">PHPUnit unit tests<div class="collapseAction"><p onClick="doToggle(this)">Hide Details</p></div></div><div class="expanded"> <!--[32m--><span style="color: #00CD00;">INFO<!--[0m--></span>:quibble.commands:PHPUnit unit tests … <!--[32m--><span style="color: #00CD00;">INFO<!--[0m--></span>:quibble.commands:PHPUnit done </div>
If I recall correctly, these <!--[32m--> comments didn't use to be there. And it seems a likely that this is the trigger. It is unclear to me why .*INFO:quibble would start its match mid-way this HTML comment. On the other hand, this HTML comment only exists because of the AnsiColor code handling.
Impact
As far as I know, this regular expression is meant to run on the text form, not on the HTML form. Running it on the HTML form would be unsafe as the patterns don't take escaping into account, e.g. it might match a tag midway and change its meaning.
Or, in this case, it means the </div> is actually closing an unrelated element and the entire page is distorted: