The last merged change did pass jsduck:

https://gerrit.wikimedia.org/r/89229
https://integration.wikimedia.org/ci/job/mediawiki-core-jsduck/2672/

The bug is referencing change: https://gerrit.wikimedia.org/r/#/c/86867/ which now eventually pass.

I'm rephrasing this bug to what is the real bug, which incidentally is contradictory to your premise.

Jobs should fail regardless of whether files that seemingly caused it were altered in said patch set. Master is always passing (enforced by our gate), and if a patchset made it fail, that needs to be addressed first. If someone bypassed the gate or if Jenkins was changed without being backwards compatible either that change needs to be rollbacked or someone is presumably already working on hotfixing the (whether or not anticipated) breakage.

I'm not necessarily saying jobs absolutely must fail if the error seems to have been there already without this patchset. Merely that the problem it is causing now is actually something very different, and in general I believe at at this point anything we'd do to "ignore" errors will do more harm than good (e.g. changing jshintrc can seriously alter and break things even though the error message will not appear to originate from that file, and changes might fix one error and introduce another).

Worked around by making the jsduck Jenkins jobs to grep for 'Warning' and exit non zero in such a case: https://gerrit.wikimedia.org/r/#/c/113033/

Lowering priority (we have a workaround) and marking bug as depending on upstream.

Upstream bug is https://github.com/senchalabs/jsduck/issues/525

Change 174619 had a related patch set uploaded by Krinkle:
jsduck: Remove redundant hack that searched jsduck.log for "Warning"

https://gerrit.wikimedia.org/r/174619

Change 174619 merged by jenkins-bot:
jsduck: Remove redundant hack that searched jsduck.log for "Warning"

https://gerrit.wikimedia.org/r/174619