1180742 - Give TH the ability to trigger all talos jobs for a revision multiple times

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect)

Description

[Armen [:armenzg]]

This is very useful for multiple reasons:

1) We have a merge day which uplift gecko versions and we would like a new talos baseline

2) A developer would like to get an accurate talos baseline for a Try push

3) No one needs to set up mozci locally, specially for when we move to TC

Comment 1

[Vaibhav (:vaibhav1994)]

Attachment: screen-shot 1

Comment 2

[Vaibhav (:vaibhav1994)]

Attachment: screen-shot 2

Comment 3

[Vaibhav (:vaibhav1994)]

Attachment: screen-shot 3

Comment 4

[Vaibhav (:vaibhav1994)]

Attachment: screen-shot 4

Joel, I have attached sequential screen shots for "Trigger Missing Talos Jobs" here. When clicking on the button, it will warn the user (that they are triggering all talos jobs), and then ask for number of times to trigger the jobs. I would like your feedback if this look fine? 

PS: We will ultimately be able to send (branch, revision, "all_talos", times) action to pulse with this.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

Comment on attachment 8634579 [details]
screen-shot 4

I am excited by this a few thoughts:
1) will this only work for the given revision, or will it backfill all missing talos jobs?
2) if we are triggering jobs for a specific revision, we should default to 6 data points- I don't see another reasons to ensure all jobs are run for a revision unless we have the larger volume of data points.
3) if we are triggering all jobs,that would indicate we have either a regression and we want all data points, or we want to compare against something (say aurora vs central, or e10s vs non e10s).  In this case we want all jobs trigger for this revision and the previous one.  Although we could leave that off the table as the previous revision might be a failed build, so we could manually select the revision to compare against.
4) will this do opt only, pgo, pgo only, ?  It should not be scheduling new pgo jobs unless we are on aurora/beta.

Comment 6

[Vaibhav (:vaibhav1994)]

Thanks for your feedback Joel.
To answer your questions:
(In reply to Joel Maher (:jmaher) from comment #5)
> 1) will this only work for the given revision, or will it backfill all
> missing talos jobs?
It will trigger all talos jobs for the given revision. If one wants to backfill talos missing jobs, one can do that by clicking on that particular job and clicking the "Backfill this job" button that will get checked-in soon in bug 1178524

> 2) if we are triggering jobs for a specific revision, we should default to 6
> data points- I don't see another reasons to ensure all jobs are run for a
> revision unless we have the larger volume of data points.
Yes, I can easily change the default value to 6, just kept it 1 for time being. This will be a sheriff-only option so hopefully it will not be misused.

> 3) if we are triggering all jobs,that would indicate we have either a
> regression and we want all data points, or we want to compare against
> something (say aurora vs central, or e10s vs non e10s).  In this case we
> want all jobs trigger for this revision and the previous one.  Although we
> could leave that off the table as the previous revision might be a failed
> build, so we could manually select the revision to compare against.
Yes, right now I think it is safe to trigger all talos jobs only for the current revision. That will ensure prevent unnecessary triggering. Since this will be calling all_talos script in mozci, we can easily change the logic there to trigger talos jobs of previous revision, if need be.

> 4) will this do opt only, pgo, pgo only, ?  It should not be scheduling new
> pgo jobs unless we are on aurora/beta.
This will be calling all_talos script in mozci, so will be triggering the jobs that are triggered by it. I am not sure what all are skipped/triggered, since you have written that script :)

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

lets get this in with the default of 6 and we can tweak it as needed!

Comment 8

[Vaibhav (:vaibhav1994)]

Attachment: pr #779

:mdoglio, could you please review this patch?

Right now, I am sending requests to 'trigger_all_talos_jobs' in a for loop for the number of times they need to be triggered. I am not sure if we can send these requests in a single url with SimpleRouter() in django. Also, it needs to be compliant with other resultset actions. Let me know if there is a better way.

Comment 9

[Vaibhav (:vaibhav1994)]

Comment on attachment 8634892 [details] [review]
pr #779

Added a query parameter for 'times'. :mdoglio, can you please review this?

Comment 10

[Ed Morley [:emorley]]

_Please_ can bugs with a PR affecting Treeherder be in a Treeherder component? If work needs a Treeherder part and a non-treeherder part, it's better to use two bugs. This time (and the several before it) the PRs in question escaped the PR closing monster that I hear roams Github, the next time the poor PR may not be so lucky ;-)

Comment 11

[Treeherder GitHub Bugbot]

Commits pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/c7a0f1e96b778882e0cabb2310580881a5a0d4bd
Bug 1180742-Publish 'trigger_all_talos_jobs' for a revision to pulse

https://github.com/mozilla/treeherder/commit/27eca89e21fa9bc20b4b9455a7fba31e46d016f9
Merge pull request #779 from vaibhavmagarwal/all-talos

Bug 1180742-Publish 'trigger_all_talos_jobs' for a revision to pulse