Last modified: 2014-04-14 21:13:28 UTC
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?)
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 https://gerrit.wikimedia.org/r/125397
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
