1274640 - Try commands with "-p win32" spawn jobs on other platforms.

Status: RESOLVED WORKSFORME

(Firefox Build System :: Task Configuration, task)

Description

[Nicolas B. Pierron [:nbp]]

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

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

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?

Comment 3

[Steve Fink [:sfink] [:s:]]

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.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

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.