Rillke wrote:
Build errors unrelated.
They're related to I24a0d1677f8870970 and the "assert.throws" not being supported in some older browsers (should they run the unit tests?)
Version: 1.23.0
Severity: normal
URL: https://gerrit.wikimedia.org/r/#/c/125337/
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Paladox | T62619 All repositories should pass jshint test | |||
| Declined | None | T65805 MediaWiki core should pass jshint |
OK, interesting.
These messages by jshint are informationals, but our jslint parsing script does not make a distinction between errors, warnings and informationals.
It seems that this informational was also recently removed from jshint 2.4.4:
https://github.com/gruntjs/grunt-contrib-jshint/issues/152
https://github.com/jshint/jshint/releases/tag/2.4.4
I have switched these cases back to es3 mode.
Change 125397 had a related patch set uploaded by TheDJ:
Switch a few test cases back into es5 mode
MediaWiki core has passed jshint for over a year. This bug seems invalid or based on a misunderstanding.
I think this was created because of the jshint error reported on this change:
https://gerrit.wikimedia.org/r/#/c/125337/
That change didn't change javascript files, so the error must've been in mediawiki-core and thus one would assume therefore MediaWiki core master is not passing jshint.
However that is not the case.
The change in question was submitted by a user not in the CR whitelist, and thus the non-executive version of jshint was run instead of the one we run on merge.
Our main version has been upgraded to 2.4.x a while back and that added an option for es3/es5. The old version does not understand this option and thus treated files with this option as an error.
The V+1 checkpieline's jshint has been upgraded since (did that yesterday), and this error no longer appears.
Either way, the pipeline that ran on CR+2 never had this error and thus master was always passing.
Sorry Krinkle, I read the comment above three times but I have no idea what it means.
Are you saying that it's expected to have jenkins-bot place V-1 on a change without errors?
(In reply to Nemo from comment #5)
The V+1 checkpieline's jshint has been upgraded since (did that yesterday), and > this error no longer appears.
So I guess users not in the Code Review (CR) whitelist (where's that?) are no longer getting "build failed".
However that is not the case.
This is just a friendly way of Krinkle explaining that I my guess was totally wrong.
(In reply to Rainer Rillke @commons.wikimedia from comment #6)
So I guess users not in the Code Review (CR) whitelist (where's that?) are
no longer getting "build failed".
In the config for Zuul, the glue between gerrit and Jenkins:
https://git.wikimedia.org/blob/integration%2Fzuul-config.git/HEAD/layout.yaml#L94