I have send a push to try [1,2], to execute only the talos benchmarks on win32, but got some result on Android, and Linux x64. Is this expected? [1] try: -b o -p win32 -u none -t g2-e10s[Windows 7] --rebuild 5 [2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=dcf5d8dcfe83a27546304366091f2b889f950201

By way of how to reproduce this sort of thing locally: # download the parameters.yml from the decision task dustin@dustin-moz-devel ~/p/m-c (default) $ curl -L https://queue.taskcluster.net/v1/task/PmN0xmc2Q1qW7L1OB6EBPQ/runs/0/artifacts/public%2Fparameters.yml > parameters.yml % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 29 100 29 0 0 41 0 --:--:-- --:--:-- --:--:-- 41 100 443 100 443 0 0 500 0 --:--:-- --:--:-- --:--:-- 500 # checkout the same revision dustin@dustin-moz-devel ~/p/m-c (default) $ hg pull -r dcf5d8dcfe83a27546304366091f2b889f950201 try pulling from try searching for changes adding changesets adding manifests adding file changes added 1 changesets with 0 changes to 0 files (+1 heads) (run 'hg heads .' to see heads, 'hg merge' to merge) dustin@dustin-moz-devel ~/p/m-c (default) $ hg up -r dcf5d8dcfe83a27546304366091f2b889f950201 0 files updated, 0 files merged, 0 files removed, 0 files unresolved # get the target set dustin@dustin-moz-devel ~/p/m-c (default) $ ./mach taskgraph target -p parameters.yml 0:00.12 Generating full task set 0:00.27 Starting new HTTPS connection (1): hg.mozilla.org 0:21.17 Generating full task graph 0:21.17 Generating target task set TaskLabel==Dq4Oz5MzQIm6dkXSDcCGiw (Marionette harness unit test) TaskLabel==EPljuEFLTbi4HMtSivtqMw (Android lint) TaskLabel==FtuGil1qR66eur9NnOESEQ (ESLint test) TaskLabel==G_GS46DBSy2vkIezvJmrOA (Mozharness integration tests) TaskLabel==GlAVC5u-TC6ZdiCgOsgSLQ (Android checkstyle) TaskLabel==LEtK8zcsTXKeK4K2aIWXIA (Android armv7 API 15+ gradle dependencies) TaskLabel==PH69evNsTUq86glk5YvCsQ (GCC) TaskLabel==alPleE0dTFGz_7w9xiv7wQ (Android armv7 unit tests) TaskLabel==fFLXl3VXRQebRg7Bmt1vgA (Clang) the output there will eventually be more helpful, but this does at least show the selected tasks. I note that they are all lint jobs, and I think those are more-or-less intended to always run, but I'll look a little more closely.

Indeed; logging the attributes for those jobs: TaskLabel==Tbl5516nSN-2c6cZLo2F4Q {u'build_platform': 'android-checkstyle', u'job': 'android-checkstyle', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==ZIp3KKhgR02c02ULQJvrpw {u'build_platform': 'android-api-15-gradle-dependencies', u'job': 'android-api-15-gradle-dependencies', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==CWjA9t-FRW6VZp9GQps-hg {u'build_platform': 'linux64-clang', u'job': 'linux64-clang', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==GafTMoMCSA-HZaZ8T9bOfg {u'build_platform': 'android-test', u'job': 'android-test', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==Gm5Q9zvKS-mAov4SdW2V6Q {u'build_platform': 'eslint-gecko', u'job': 'eslint-gecko', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==ela69JWtSaSFtqYhisutqQ {u'build_platform': 'android-lint', u'job': 'android-lint', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==Wf0Gefn0QzCSUsho8vOS0w {u'build_platform': 'linux64-gcc', u'job': 'linux64-gcc', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==VJzVOq0oQii-55GGQk7zXA {u'build_platform': 'mozharness', u'job': 'mozharness', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} TaskLabel==eiEjANyCSb-xAzyMRbPHaQ {u'build_platform': 'marionette-harness', u'job': 'marionette-harness', u'kind': u'legacy', u'legacy_kind': u'job', u'build_type': 'opt'} all are legacy_kind=job, and the default for -j is -j all. Greg, this was my read of how it worked in the "old" TC try parser. Is this the intent?

The GCC and Clang tasks are not lint; they're compiling those compilers. I don't know what triggers those. I don't understand what the Marionette harness unit test is doing in there, but yeah, it seems lint-like. I guess it must be http://dxr.mozilla.org/mozilla-central/source/testing/taskcluster/tasks/branches/base_jobs.yml#484 As opposed to fx_linux64_marionette.yml: description: Marionette unittest run ;-) Oh. All of this stuff is from the funky 'root' tasks. The tests have the 'platforms' entry to link them to their builds. Hmm... dustin, would this "just work" if all those root tasks added a tags entry? eg linux64-gcc: task: tasks/builds/linux64_gcc.yml root: true tags: - linux when: file_patterns: - 'build/unix/build-gcc/**' - 'testing/taskcluster/scripts/misc/build-gcc-linux.sh' Hm. Except that the android ones are ugly. You'd have to list tags: - android-api-9 - android-api-15 - android-api-15-gradle-dependencies - android-api-15-frontend - android-x86 to match what we have right now. If you don't mind feeding the complexity monster, I suppose you could have a tag aliases thing, sort of like the existing base_job_flags.yml's flags.aliases, except you'd be using them the other way around. Bleh. No obvious solution here, and I'm not sure whether this is all going to go away or something anyway. Dustin, I know this isn't a priority issue, but is there an obvious approach that fits in with your new setup? If you know what you'd like it to look like, I could probably help with this.

I don't actually know what the intent is. When "root jobs" were introduced, they ran on every try push that didn't specify `-j <something-other-than-all>`. I'm sure we can do better! From what you're suggesting with "tags", it sounds like those would be matched against platforms? In which case, maybe "platform" is a better name? Anyway, I'm going to throw this on the pile with bug 1244176 in terms of finding better ways to decide which try jobs to run when.

In fact, I think this is working as expected. Those additional jobs all have "when.files_changed" specified so they only run when something related has changed. Jobs can now be configured to run by default, or not, per branch. So I think we'll leave this as-is for now, and as particular jobs seem to run too much we can adjust their 'run-on-projects' settings.