Uh oh!
There was an error while loading. Please reload this page.
tools: remove lint-js.js - #30955
Conversation
nodejs-github-bot
commented
Dec 13, 2019
richardlau
left a comment
There was a problem hiding this comment.
We will need to check the removed lines from vcbuild.bat are not used anywhere in the CI.
Uh oh!
There was an error while loading. Please reload this page.
Trott
commented
Dec 13, 2019
Yeah, running full CI to check, although obviously that won't necessarily catch things in other jobs. Kinda doubt it would be in other jobs and not in the main one, though. |
nodejs-github-bot
commented
Dec 14, 2019
Before removing, it would be a good idea to see the performance impact on all of the CI machines (especially the ARM-based ones). |
Trott
commented
Dec 14, 2019
We only run lint on one machine these days. |
richardlau
commented
Dec 14, 2019
Looks like the linter job failed to parse the tap file with tap2junit: 02:42:08 + tap2junit -i test-eslint.tap -o out/test.xml02:42:09 Traceback (most recent call last):02:42:09 File "/usr/local/bin/tap2junit", line 11, in <module>02:42:09 sys.exit(main())02:42:09 File "/usr/local/lib/python2.7/dist-packages/tap2junit/__main__.py", line 44, in main02:42:09 result = parse(os.path.splitext(args.input.name)[0], data)02:42:09 File "/usr/local/lib/python2.7/dist-packages/tap2junit/__main__.py", line 15, in parse02:42:09 t = TestCase(test.description, None, test.yaml['duration_ms'])02:42:09 TypeError: 'NoneType' object has no attribute '__getitem__'02:42:09 POST BUILD TASK : FAILURE |
Trott
commented
Dec 14, 2019
That's alarming. It parses just fine when I do it locally.... |
Trott
commented
Dec 14, 2019
Argh, the version of |
|
Oh, interesting. So I managed to replicate the bug that I mention above where I surmise that its interleaved output or something, but actually it's a bug in Input file: TAP version 131..1ok 1 - /Users/trott/io.js/.eslintrc.jsTAP version 131..2ok 1 - /Users/trott/io.js/benchmark/net/tcp-raw-pipe.jsok 2 - /Users/trott/io.js/benchmark/net/tcp-raw-s2c.jsWith $ tap2junit -i test.tap -o fooTraceback (most recent call last): File "/usr/local/bin/tap2junit", line 11, in <module> sys.exit(main()) File "/usr/local/lib/python2.7/site-packages/tap2junit/__main__.py", line 44, in main result = parse(os.path.splitext(args.input.name)[0], data) File "/usr/local/lib/python2.7/site-packages/tap2junit/__main__.py", line 11, in parse tap_parser.parse(data) File "/usr/local/lib/python2.7/site-packages/tap2junit/tap13.py", line 124, in parse self._parse(StringIO.StringIO(source)) File "/usr/local/lib/python2.7/site-packages/tap2junit/tap13.py", line 102, in _parse raise ValueError("Descending test id on line: %r" % line)ValueError: Descending test id on line: 'ok 1 - /Users/trott/io.js/benchmark/net/tcp-raw-pipe.js'
$0.1.5 processes it normally. Any chance we want to update to 0.1.5, at least on the linter boxes? It contains the changes for Python 3 compatibility, if that's any encouragement. /ping @nodejs/python |
Trott
commented
Dec 14, 2019
(And, naturally, it seems exceedingly likely that the other problem we're seeing now with the tap file from this PR is also a bug in |
Trott
commented
Dec 14, 2019
@nodejs/build ^^^^^^ |
StringIO.StringIO(source) in Python2 would be io.StringIO(source) in Python 3 so I would strongly encourage the use of the latest version of tap2junit. https://github.com/nodejs/tap2junit/search?q=stringio&unscoped_q=stringio |
mscdex
commented
Dec 14, 2019
So we should just upgrade tap2junit instead of making the changes in this PR? |
Trott
commented
Dec 14, 2019
Perhaps. There's still the issue of cost/benefit ratio where cost is code complexity and extra time spent troubleshooting issues like this. But yeah, this PR suddenly becomes less compelling for sure. |
apapirovski
left a comment
There was a problem hiding this comment.
Whether or not this fixes the issue, given the minimal improvements in run time and extra incurred complexity, I think removing this is actually still a good thing.
richardlau
commented
Dec 17, 2019
Based on https://ci.nodejs.org/job/node-test-linter/buildTimeTrend it looks like only the jobs that ran on test-packetnet-ubuntu1604-x64-2 are yellow: |
rvagg
commented
Dec 20, 2019
test-softlayer-ubuntu1604-x64-1 too, it's just offline for now cause it's wonky and needs some of my time https://ci.nodejs.org/label/jenkins-workspace/ are the machines. |
BridgeAR
commented
Dec 24, 2019
Ref: eslint/eslint#3565 I suggest to remove this as soon as the feature landed in eslint itself but not before? It should hopefully not take much more time to be implemented. |
Trott
commented
Jan 27, 2020
Going the other way, the |
Trott
commented
Jan 27, 2020
tap2junit updated for Python 2 on test-packetnet-ubuntu1604-x64-2. It was already on the correct version on test-packetnet-ubuntu1604-x64-1. Removing |
nodejs-github-bot
commented
Jan 27, 2020
Trott
commented
Jan 27, 2020
test-softlayer-ubuntu1604-x64-1 too. |
8ae28ff to
2935f72Comparejasnell
commented
Jun 25, 2020
Ping @Trott |
lint-js.js was implemented before ESLint had a caching feature. It is now only used in CI. Let's remove it on the following grounds: * It results in occasional (and puzzling) yellow CI runs for node-test-linter because the tap file is corrupted somehow. Interleaved maybe? I don't know, but a simple solution is removing it and running ESLint directly. * On my local laptop, it reduces the linting from about 75 seconds to about 55 seconds. This kind of savings is not worth the added complexity and the instability noted above.
lint-js.js was implemented before ESLint had a caching feature. It is now only used in CI. Let's remove it on the following grounds: * It results in occasional (and puzzling) yellow CI runs for node-test-linter because the tap file is corrupted somehow. Interleaved maybe? I don't know, but a simple solution is removing it and running ESLint directly. * On my local laptop, it reduces the linting from about 75 seconds to about 55 seconds. This kind of savings is not worth the added complexity and the instability noted above. PR-URL: #30955 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
jasnell
commented
Jul 3, 2020
Landed in 92f8781 |
lint-js.js was implemented before ESLint had a caching feature. It is now only used in CI. Let's remove it on the following grounds: * It results in occasional (and puzzling) yellow CI runs for node-test-linter because the tap file is corrupted somehow. Interleaved maybe? I don't know, but a simple solution is removing it and running ESLint directly. * On my local laptop, it reduces the linting from about 75 seconds to about 55 seconds. This kind of savings is not worth the added complexity and the instability noted above. PR-URL: #30955 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
lint-js.js was implemented before ESLint had a caching feature. It is now only used in CI. Let's remove it on the following grounds: * It results in occasional (and puzzling) yellow CI runs for node-test-linter because the tap file is corrupted somehow. Interleaved maybe? I don't know, but a simple solution is removing it and running ESLint directly. * On my local laptop, it reduces the linting from about 75 seconds to about 55 seconds. This kind of savings is not worth the added complexity and the instability noted above. PR-URL: #30955 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
lint-js.js was implemented before ESLint had a caching feature. It is now only used in CI. Let's remove it on the following grounds: * It results in occasional (and puzzling) yellow CI runs for node-test-linter because the tap file is corrupted somehow. Interleaved maybe? I don't know, but a simple solution is removing it and running ESLint directly. * On my local laptop, it reduces the linting from about 75 seconds to about 55 seconds. This kind of savings is not worth the added complexity and the instability noted above. PR-URL: #30955 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>

lint-js.js was implemented before ESLint had a caching feature. It is
now only used in CI. Let's remove it on the following grounds:
It results in occasional (and puzzling) yellow CI runs for
node-test-linter because the tap file is corrupted somehow.
Interleaved maybe? I don't know, but a simple solution is removing it
and running ESLint directly.
On my local laptop, it reduces the linting from about 75 seconds to
about 55 seconds. This kind of savings is not worth the added
complexity and the instability noted above.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes