build: do not lint src dir for JS errors

[Trott]

Checklist

• make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

build

Description of change

There are no JavaScript files in the src directory. It can be
safely omitted from the JavaScript linting step.

[cjihrig]

LGTM

[jbergstroem]

LGTM if ci passes.

[silverwind]

LGTM

[Trott]

CI is green: https://ci.nodejs.org/job/node-test-pull-request/3696/

[jbergstroem]

@Trott bro join the game – it says so below! "11 successful checks"

[Trott]

@jbergstroem I know but I have a few reservations with relying on that:

• Race condition: If someone else starts another CI for this PR (either by accident by mistyping their PR_ID in the Jenkins form, or by starting it at about the same time I start mine so we have two running nearly in parallel), it will (or might) overwrite the results. I don't want the successful CI run to be lost.
• It's not clear to me that the GitHub display is permanent. When the CI results are wiped cleared in a few weeks, will it still show here as green? I imagine it will, but I don't actually know that. And since I've definitely come across PRs in the past that land and I'm all like, "Hey, this didn't get a CI run" (which I usually notice because the PR broke the CI)... you know, I want to be able to look at this one in a year and know that it had a green CI run.

These concerns may be me inventing things to worry about and in another three days, I'll be all like, "Hey, why are you posting the CI results in a comment? They're right there below. Johan worked hard on that. Don't waste our time with email notifications telling us what's plainly there in the comment. Who does that?!?!" But I'm not there yet.

I used "all like" twice in this comment. Deal with it.

[addaleax]

Also, if I observed it correctly, updating PRs – be it by adding another commit or by rebasing it – does clear the status display on Github, too. I think that alone is reason enough to keep posting these comments.

[jasnell]

LGTM

[jbergstroem]

@Trott: I actually didn't know that the build checks were removed in time. Is that really the case? What I do know is that once we set another pending job with the same identifier the old job success/fail will be removed.

Regarding parallel jobs to the same pr: I guess we can add some barrier in the gh bot, but that check probably should live at Jenkins.

[Trott]

@jbergstroem I guess the bottom line is that how the status gets posted to the PR is currently largely a mystery to me so I'm being cautious.

Maybe I should get more involved on that end of things...

[jbergstroem]

@Trott we'll figure it out as we go. @addaleax's point about keeping build info around for older CI runs (if we rebase, etc) is relevant though. Not sure how to handle that 'automated'.

[Trott]

Landed in dbbbf21

[MylesBorins]

labeling don't land, please feel free to batch in with other linting updates if desired