1615001 - failed to schedule android-lints job on try and patch gets backed out on autoland

Status: RESOLVED FIXED

(Release Engineering :: Firefox-CI Administration, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

this week :dminor pushed to try and got all green:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7e603e551e39903e01bb1ca95c30983fa6d05016

then on autoland the lints job failed:
https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=20e979be216b6830d0b1a9f1c657f4ce3199fd20

I looked around and the lints job and related failures have been around for months, which indicates that this isn't an unfortunate timing issue where the lints job or new lint rule was added between try push and autoland push.

Maybe it is a fluke. Looking in the decision task, I see no evidence of the job being added or removed. The lints job would have been scheduled based on a files-changed ruleset:
https://searchfox.org/mozilla-central/source/taskcluster/ci/source-test/mozlint-android.yml#102

matching **/*.gradle

That explains why it was scheduled on autoland. I do not see it scheduled on Dan's try pushes, yet I see the lints job scheduled on many other try pushes (personal and reviewbot).

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

:tomprince, do you know who in taskcluster could help debug this and reduce the chance of this happening in the future?

Comment 2

[Tom Prince [:tomprince]]

The task does not have the always-target attribute set, and was not directly requested by the try push, so it was not run.

The files-changed setting controls when a task gets optimized to not run, but doesn't cause the task to run otherwise.

---

In more detail:

A task is included in the target task set based on the target_task_method (for most try selectors, this is based on the explicit list in try_task_config.json, on other branches it is mostly primarily based on run-on-projects).

The target task graph includes the target task set, all docker images, and all tasks with always-target[1] and the recursive dependencies of all those tasks.

Then optimization removes and/or replaces tasks in the target task graph, to get what will actually run[2].

Since the mozlint-android task did not end up in the target-graph, optimization (like files-changed) had no effect on it.

[1] for on-push graphs; for cron and other (i.e. release promotion) graphs, the always-target tasks are not included
[2] morphs are applied after optimization, but aren't relevant here

Comment 3

[Nick Alexander :nalexander [he/him]]

(In reply to Tom Prince [:tomprince] from comment #2)

The task does not have the always-target attribute set, and was not directly requested by the try push, so it was not run.

The files-changed setting controls when a task gets optimized to not run, but doesn't cause the task to run otherwise.

---

In more detail:

<snip> Thanks Tom, this is very helpful. Looks like we just need to add always-target: true to mozlint-android.yml (which is just like mozlint.yml, that does contain it). I'll submit.

Comment 4

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1615001 - `always-target` android-lints like other mozlints. r?tomprince

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/154826a580cf
`always-target` android-lints like other mozlints. r=tomprince

Comment 6

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/154826a580cf