1180341 - Add notifications when android lint throws an error

Status: RESOLVED DUPLICATE of bug 1238788

(Firefox for Android Graveyard :: General, defect)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

So we can enforce the lint results and ensure we don't regress issues we've already fixed.

Ideally, this would be Treeherder but it may take a lot of effort to do that so we should look into alternatives. Ideas:
  * (Like Hello) Cron job that pulls fx-team every few hours, runs lint, and sends an email if it fails
  * Run lint locally on every build (perf impact...?)
  * Another CI system

Nick, I forgot our previous conversation :( - do you have any opinions or other ideas?

Comment 1

[Nick Alexander :nalexander [he/him]]

(In reply to Michael Comella (:mcomella) from comment #0)
> So we can enforce the lint results and ensure we don't regress issues we've
> already fixed.

This is tricky because there's a good deal of prep needed to actually lint a tree.  You need to at least run |mach configure| and have enough compile environment to pre-process some things, like strings.xml.  Right now |mach gradle-install| requires running |mach build && mach package| first, but that's artificial: we could minimize what needs to be run.  That is, we could make it so |mach configure && mach build-backend && mach gradle lint ...| works.  That's not easy.

> Ideally, this would be Treeherder but it may take a lot of effort to do that
> so we should look into alternatives. Ideas:
>   * (Like Hello) Cron job that pulls fx-team every few hours, runs lint, and
> sends an email if it fails

This is most likely to actually do good things and be easy.  ci.mozilla.org runs Jenkins, which makes this pretty straight-forward.  I think.

>   * Run lint locally on every build (perf impact...?)

The perf impact is significant.  If you want, add it as an opt-in, but it shouldn't be the default.

The fastest way to get benefit today might be to make this part of every /automation/ build... but that requires getting Gradle and Maven dependencies into tooltool and onto the buildbots, and it's frustrating to be backed out for a thing that doesn't fail locally.  Choices...

>   * Another CI system

Eventually Task Cluster should make this less frustrating, but that day is a ways away.  It's fun to mess with Task Cluster today (start at https://tools.taskcluster.net/) anyway...
 
> Nick, I forgot our previous conversation :( - do you have any opinions or
> other ideas?

Consider doing this with travis?  In theory you can run travis jobs after pushes to gecko-dev.

These kind of "yellow warning" jobs are hard to handle :(

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Nick showed me some task cluster stuff he's been working on so I think he should be assigned here.

Comment 3

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

I think Nick is doing this work in bug 1238788.