746146 - PGO scheduling optimizations

Status: RESOLVED DUPLICATE of bug 691675

(Release Engineering :: General, defect)

Description

[Armen [:armenzg]]

Currently *I* believe we are over-triggering jobs.

* For m-c/m-a we trigger unnecessarily pgo jobs because there is nothing better to do:
https://tbpl.mozilla.org/?jobname=pgo&rev=c61e7c3a232a
** 3 full sets of PGO
https://tbpl.mozilla.org/?tree=Mozilla-Aurora&jobname=pgo&rev=01ae9ced59c6

* For m-a/m-b/m-r we trigger both PGO and non-PGO builds
** I believe we should avoid the non-PGO builds
** It saves CPU build time
** We don't run unit tests and talos for non-PGO builds
** These 3 branches are not as sensitive as the other ones (perhaps not the case for m-b when chemspills)
** e.g.
https://tbpl.mozilla.org/?tree=Mozilla-Aurora&rev=01ae9ced59c6
https://tbpl.mozilla.org/?tree=Mozilla-Beta&rev=0ba53003ae26

[1] http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla-tests/config.py#l1077

Comment 1

[Phil Ringnalda (:philor)]

That's two separate things:

* on m-c (an much more severely, fx-team and services-central) we trigger periodic PGO whether or not the tip rev has already built PGO, bug 691675

* on m-a/m-b/m-r, we only build PGO, but we confuse the issue by putting PGO in the name of the test jobs, but not the name of the builds, so tbpl winds up showing the builds as non-PGO and the tests (including tests on the nightly build) as PGO, making you think there are two builds when in fact we never build non-PGO on those branches, bug 700924