Closed Bug 1076687 Opened 10 years ago Closed 8 years ago

treeherder/scheduler: Add api for "retriggers"

Categories

(Taskcluster :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jlal, Unassigned)

References

Details

We need to manually "retrigger" a particular job ... the work here is specificly for integrating with treeherder so the retrigger buttons work correctly for TC jobs. This may involve changes in our core apis but more likely just a wrapper + auth.
Blocks: 1076681
In taskcluster we call these retriggers reruns, @lightsofapollo, correct me if you're not talking about TC reruns.

Anyways, the end-point will take taskGraphId and taskId as arguments, possibly also a small JSON blob...
Authentication will be with hawk, we can create one set of credentials that will work for all tasks.
Note, that taskGraphId and taskId will need to somehow be added to the jobs by taskcluster-treeherder, see:
https://github.com/taskcluster/taskcluster-treeherder/blob/master/treeherder/handlers.js
I hope treeherder people can decide how we stuff that in there. Our current submission is guess work.

I'll take charge of implementing the taskcluster side, where we currently need to add this end-point to the task-graph scheduler.

@emorley,
How do you authenticate if a user is allowed to retrigger a job?
Is this based on persona login, email address of author?
I will happily give treeherder credentials to retrigger any job in any task-graph, but I need assurances that you won't expose this. In particular treeherder will need a server side check to ensure that the taskGraphId and taskId it is trying to retrigger for has been reported to treeherder.
This is the minimum requirement, I don't want treeherder expose permissions to retrigger tasks that haven't been reported to treeherder.

It is of course tempting to add a "creatorId" to the task-graph, similar to schedulerId on tasks, such that only someone who can assume the "creatorId" can retrigger, extend and otherwise modify the task-graph. This way we can expose restricted scopes to treeherder.
This work is purely for the treeherder integration which is why I intentionally used the term "retrigger" what calls we actually make into TC may depend on graph state (our discussion yesterday). Also like you mentioned we may need to use a different auth mechanism to get this to play nicely with treeherder.
Since, this is filed under "testing > taskcluster", I assume this is about providing an API that treeherder
can call; presumably on the scheduler.
Basically, I need to know how treeherder will expose this feature to users. If TH isn't good at protecting from us from people injecting arbitrary taskGraphId and taskIds, we'll have to scope the API on the scheduler appropriately.

I assume the authentication and invocation of the API to retrigger a job has to take from treeherder.
Buildbot jobs retriggers use buildapi/self-serve, which is behind LDAP (and so prompts for HTTP auth on first use of the feature each session). As such, treeherder doesn't add any additional auth (but did in the early days before the situation was understood).

As such, sounds like we perhaps just want to use the treeherder Persona auth to ensure that users are logged in before they can request retriggers. I would imagine any logged in user will need to have permissions to perform a retrigger, not just a special group.
(In reply to Ed Morley [:edmorley] from comment #4)
> As such, sounds like we perhaps just want to use the treeherder Persona auth
> to ensure that users are logged in before they can request retriggers

...like we used to do for buildbot prior to bug 1032152.
See Also: → 1077053
We can also do the authentication in taskcluster... I would perfectly okay with that.
If treeherder doesn't already authentication, I suggest we put in taskcluster.
I'm already planning to build a tools.taskcluster.net site that will provide you allow to login with persona and retrigger tasks, download protected artifacts, create tasks,, inspect statistics, etc...

Then treeherder can just redirect to a URL, in fact we can probably add it.
Blocks: 1080265
Depends on: 1078520
See Also: → 1113281
No longer blocks: 1076681, 1080265
It's really painful when you have to enable testsuites on a target ...
Component: TaskCluster → General
Product: Testing → Taskcluster
This now happens via mozilla-taskcluster.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.