try: -p all shouldn't trigger tier-3 jobs



Release Engineering
2 years ago
a month ago


(Reporter: glandium, Assigned: aselagea)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



2 years ago
Pushing to try with -p all currently triggers tier-3 jobs. That's a whole bunch of b2g jobs, hidden by default on treeherder because tier-3, and that are busted anyways. Why are we wasting resources spinning these tier-3 builds by default?

Comment 1

2 years ago
Created attachment 8731627 [details] [diff] [review]

Added the patch to prevent running tier 3 buildbot builds by default. 

However, most of the tier 3 jobs mentioned by Mike are managed by taskcluster, so we will need to do this change as well.
Attachment #8731627 - Flags: review?(kmoir)


2 years ago
Attachment #8731627 - Flags: review?(kmoir) → review+


2 years ago
Assignee: nobody → alin.selagea


2 years ago
Attachment #8731627 - Flags: checked-in+

Comment 3

2 years ago
In order to prevent tier 3 jobs to run by default when pushing to try with "-p all", I assumed that "/try/testing/taskcluster/tasks/branches/base_jobs.yml" contains the builds and tests that will be run by default, while "/try/testing/taskcluster/tasks/branches/try/job_flags.yml" contains the builds and tests that will be run only if explicitly specified. 

If that was valid, we could have tried to create a new .yml file (like "try_base_jobs.yml") to store all the entries from "base_jobs.yml" minus the ones related to the tier 3 jobs that we no longer want to run by default. Those would have been moved to "/try/testing/taskcluster/tasks/branches/try/job_flags.yml". 

However, it seems that this approach is not valid, as running something like:
./mach taskcluster-graph --pushlog-id 726246 --project=try --owner --message 'try: -b do -p all -u all -t all' --revision-hash=72fbf603ca5e32bb7f17695f95def48dd2c153b5 --extend-graph

on my local machine would trigger all the jobs specified on the two files.

Any suggestions would be much appreciated. Thanks!
Flags: needinfo?(dustin)
I don't have any great ideas for you.  I believe Armen accomplished something like this a while back, removing some jobs from being run by default.
Flags: needinfo?(dustin) → needinfo?(armenzg)

Comment 5

2 years ago
I would add the tier level metadata to the jobs.
If they're not tier1 and we have not included them explicitely we simply drop them. Watch for associated test jobs for those non-tier1 builds.

I never accomplished this. We've only been able to adjust Buildbot *builds* to not run by default.

On TaskCluster I cheated with linux64 by naming it linux64_tc which would not trigger Linux builds on Buildbot. It is a different matter.
Flags: needinfo?(armenzg)
Alin: we actually already provide this information, in $MOZ_SCM_LEVEL.  See for example.

Level 1 is try.  So the approach Armen's suggesting would involve modifying testing/taskcluster/taskcluster_graph to omit tasks tagged with treeherder tier 3 and omit them when making a try build.  That still leaves some bits unsolved, but hopefully it's a good start.  Want to give it a try?

Comment 7

2 years ago
Armen and Dustin thanks for the suggestions!

Well, I'll be on PTO next week but if no rush with this, then I'd definitely like to see what I can do.

Comment 8

6 months ago
The only tier 3 jobs I'm currently seeing on try are Linux64 SpiderMonkey builds and telemetry tests, so I don't think this is an issue any longer. Closing.
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.