RFC 0051 - Optimize Taskcluster retriggers to avoid Action tasks cong…

[JohanLorenzo]

…estion

[jcristau]

The backlog was caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1992376. If it wasn't for that bug, retrigger action tasks would have taken a minute or two each, and running 1000 wouldn't have been a problem. So I don't think we should design for that.

[JohanLorenzo]

Understood. I believe we make the experience faster in terms of retriggering tests. Instead of having developers wait for:

1. a rt action task to be picked and run
2. the actual task to run.

We can shave a few minutes for developers. What do you think @jcristau?

[jcristau]

I don't understand how you expect that to work. For one thing, we don't grant people the scopes to retrigger tasks directly, and I would be very wary of changing that, the implications are quite broad. For another, attributes are a taskgraph thing, they're not part of the actual tasks.

[JohanLorenzo]

For one thing, we don't grant people the scopes to retrigger tasks directly, and I would be very wary of changing that, the implications are quite broad.

I understand that, at the moment, retriggering a task requires scopes like queue:create-task. What if we created a new scope for the specific action of retriggering an existing task? Would that be good enough?

For another, attributes are a taskgraph thing, they're not part of the actual tasks.

I see retrigger attributes can get converted into a task tag. We can leverage task tags. What do you think?

[JohanLorenzo]

Converting PR back to draft while I flesh out the proposal more. At the moment, I compiled the history of Action tasks and retriggers for the sake of understanding what the problem to solve back then.