1267848 - Try push appearing to pick up extra task cluster tasks

Status: RESOLVED WORKSFORME

(Taskcluster :: General, defect)

Description

[David Burns :automatedtester]

When Dolske pushed to try there are a number of jobs that were what he expected like Marionette Harness tests, linter, and linux64 jobs.

Since there appears to be doing more work than necessary we should probably check as we add new TC tasks that they arent added to everyones job unless it is necessary. The Marionette Harness tests definitely dont need to be run on everyones Try push.

Comment 1

[Selena Deckelmann :selenamarie :selena]

Referenced task is: https://tools.taskcluster.net/task-graph-inspector/#eJChYGA0Q5abGFDnODqK4A/YySxNPYpS9KhsreFzTEfTA/

Comment 2

[Justin Dolske [:Dolske]]

Just for context, I was looking at https://treeherder.mozilla.org/#/jobs?repo=try&revision=be2092621c4b, the result of "mach try -b do -p android-api-15 toolkit/components/passwordmgr/test/mochitest/"

Obviously the Android B and M(1) should be there, as should the ever-present "gecko-decision opt", but I don't understand what the other things are or why they're shown. Specifically:

  * Linux x64 opt            Cc(Clang GCC) tc[tier 2] (Mn-h)
  * Android 4.0 API15+ opt   B tc[tier 2] (B Deps checkstyle lint)
    ...the first "B" is expected, what's the second under tc?
  * lint opt                 tc[tier 2](ES) tc(MH)

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Looks like an issue with the taskcluster decision task, or the config for that.

Comment 4

[Geoff Brown [:gbrown]]

I think "Android 4.0 API15+ opt   B tc[tier 2] (B Deps checkstyle lint)" is expected for any android-api-15 build. The Linux x86 stuff seems very unexpected.

Comment 5

[Jordan Lund (:jlund)]

(In reply to Geoff Brown [:gbrown] from comment #4)
> I think "Android 4.0 API15+ opt   B tc[tier 2] (B Deps checkstyle lint)" is
> expected for any android-api-15 build. 


iiuc, lint and checkstyle jobs can only be triggered if (1) explicitly defined in commit msg, (2) all is passed in commit msg, or (3) when certain files change. I'm not an expert but that is what I am reading from: https://dxr.mozilla.org/mozilla-central/source/testing/taskcluster/tasks/branches/base_jobs.yml#318


> The Linux x86 stuff seems very unexpected.

similar situation here.

what was the actual commit that was being tried on try? https://hg.mozilla.org/try/rev/7371c3eed60049341c9dfd2f4c7b6d63ccf821bf ? was this a no-op change? Maybe that causes a bug..

I ask because, like lint and checkstyle, the following code suggests Clang tasks seem to be scheduled implicitly when certain files have changed in the commit. See: https://dxr.mozilla.org/mozilla-central/source/testing/taskcluster/tasks/branches/base_jobs.yml#349

*hand waving* not an expert, just adding my 2c

Comment 6

[Geoff Brown [:gbrown]]

(In reply to Jordan Lund (:jlund) from comment #5)
> (In reply to Geoff Brown [:gbrown] from comment #4)
> > I think "Android 4.0 API15+ opt   B tc[tier 2] (B Deps checkstyle lint)" is
> > expected for any android-api-15 build. 
> 
> iiuc, lint and checkstyle jobs can only be triggered if (1) explicitly
> defined in commit msg, (2) all is passed in commit msg, or (3) when certain
> files change. I'm not an expert but that is what I am reading from:

That's right. I usually modify mobile/android on my Android try pushes, so I expected to see those -- forgot that those are triggered by file changes.

So, probably no-op change + file_patterns rule = bug.

Comment 7

[Justin Dolske [:Dolske]]

(In reply to Geoff Brown [:gbrown] from comment #6)

> So, probably no-op change + file_patterns rule = bug.

Possibly. I did an earlier Try push here that also shows some unexpected stuff for Linux x64 debug, although Android looks normal: https://treeherder.mozilla.org/#/jobs?repo=try&revision=880d5dccf606

(My empty push was to verify that the Android oranges in that Try run were not something I was introducing.)

Comment 8

[Gregory Szorc [:gps]]

I'm going to argue that this is behaving as expected. If you pushed nothing, we should do nothing.

The file-based scheduling works by looking at the non-public ancestor changesets of the built revision. For https://treeherder.mozilla.org/#/jobs?repo=try&revision=be2092621c4b, the draft changesets are:

https://hg.mozilla.org/try/rev/be2092621c4b
https://hg.mozilla.org/try/rev/7371c3eed600

And the first public ancestor is https://hg.mozilla.org/try/rev/9ce31e9f90cb which is a commit on mozilla-central.

I see 5 options:

1) You can trigger jobs via Treeherder for the revision you wish to test. (Running extra jobs on central, inbound, etc shouldn't cause too much harm - unless it is a Nightly build job!)
2) You can create a dummy commit that touches files to trigger tasks you want to run (just add whitespace or something)
3) You can trigger new jobs for empty pushes using Treeherder (not sure if this works for TC tasks though)
4) We can add a "force" flag or something to Try syntax that ignores the file based scheduling
5) We can have empty pushes schedule all tasks (this seems highly undesirable)