1150267 - productionalize eslint warnings for loop

Status: RESOLVED WORKSFORME

(Hello (Loop) :: Client, defect, P3)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Over in bug 999737 I landed ESLint configuration files for browser/components/loop.  ESLint depends on node.js.  Since we can't (currently?) expect that to be available on build machines, I hacked together a poor man's solution: a cron job running on our dev server that sends me mail every 3 hours so that I can go bug people who break it.

I think there are 3 things here worth fixing:

a) repeated runs shouldn't send repeated mails, so that we can add a larger group of people to this alias and make it run more often.  This seems like the highest leverage and (I suspect) the easiest thing to fix.

b) runs should be attached to pushes so it's clear which push caused which breakage
 
c) it should be running on supported, production infrastructure

What I suspect is the cleanest fix for all of these things would be "put node.js on the build machines".  

I'm assuming, however, that there are no imminent plans for this (?), in which case I'd like to figure out how we can proceed stepwise sooner.  Perhaps there is a jenkins instance somewhere where we could put this job to cleanly solve a) and c), and something involving Treeherder to solve b)?

Needinfo-ing a few folks for their thoughts...

Comment 1

[Chris Cooper [:coop] (he/him)]

dmose: are any of the JS files that get linted created as part of the build process? If not, I think firing up a build job to lint the code as a first step is overkill. I would prefer the linting (and any other formatting- and/or style-verification) to happen *before* the code even makes it into the build pipeline, possibly as a commit hook. Code changes that pass the initial gauntlet would generate build requests.

That said, we don't have those tools today in buildbot that would mimic, say, the travis integration with github. It would not be too hard to add the node.js binaries to tooltool and then adjust the mozharness scripts to run linting as a step prior to compile.

Comment 2

[Nils Ohlmeier [:drno]]

(In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment #0)
> b) runs should be attached to pushes so it's clear which push caused which
> breakage

...

> and something involving Treeherder to solve b)?

I don't think Treeherder is going to help you with b) at all. Treeherder does give you any notifications about pushes or new builds. You tell it for which revision your new test results are.
For notification the best I know is pulse. But I believe that only gives you notifications for new builds available. Would be nice to learn if we have somewhere a notification systems which allows you to subscribe only to certain subtrees of mc.

Comment 3

[Gregory Szorc [:gps]]

You should look into Task Cluster.

Comment 4

[Mark Banner (:standard8)]

We now have something running that's working for Loop in its new dev repo. For m-c we're still working on strategies, but I don't think we need to do that here. There's also more global to FF efforts to get eslint running regularly.

Therefore I think we can resolve this as WFM for now.