1156305 - support creating tasks for jobs started by Buildbot (aka, 2 way buildbot bridge)

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[[e-mail] (:bhearsum)]

The current Buildbot <-> TC Bridge only supports injecting Buildbot BuildRequests after a Task has been created. This is what we want to do for the vast majority of things, but there's some edge cases (especially in the transition period) that will require us to create Tasks for Builds that originated in Buildbot (eg, rebuilds triggered through buildapi or automatic retries).

This probably means listening for additional events from Buildbot and creating tasks for them. One of the tricky parts is going to be how to give the Buildbot Build taskId and runId information. The way we're doing this for TC -> Buildbot jobs is through properties, but since the bridge won't be creating BuildRequests we can't use that strategy here.

Comment 1

[Jonas Finnemann Jensen (:jonasfj)]

Note,
  You'll probably want to use a different workerType name for tasks that are created purely to reflect
  state in buildbot. Obviously, these tasks are not controlled/scheduled by TC, so you don't want to
  mix them with the other tasks that are initiated from TC and then started in BB.
  See my comment on bug 1164455.

Comment 2

[[e-mail] (:bhearsum)]

(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #1)
> Note,
>   You'll probably want to use a different workerType name for tasks that are
> created purely to reflect
>   state in buildbot. Obviously, these tasks are not controlled/scheduled by
> TC, so you don't want to
>   mix them with the other tasks that are initiated from TC and then started
> in BB.
>   See my comment on bug 1164455.

Is this because we don't want the bridge to receive task-pending, task-exception, etc. events for jobs initiated in Buildbot? I think we'd want to throw away some of those events, but we'd probably want to handle cancellations initiated through Taskcluster, so we'd need to handle some of them.

The only thing the bridge uses workerType for is configuring routing keys, so I don't think it matters to it whether these jobs have the same workerType as Taskcluster-initiated jobs.

Comment 3

[Jonas Finnemann Jensen (:jonasfj)]

> Is this because we don't want the bridge to receive task-pending, task-exception, etc.
> events for jobs initiated in Buildbot?
Spot on. Also it's a different kind of task, so using a different workerType makes sense.
It makes it obvious that this is a different kind of task.

You can still listen for task-exception if you want to, it's just another extra pulse listener.
That way you also know the source and context in your message handler... You don't have to guess,
which way you're mirroring the task when you receive the task-exception message.

The only way I see it making sense to use the same workerType, is if the task.payload is constructed
in such a way that creating a clone of the task that was triggered by buildbot will create a task that
triggers a build in buildbot. Some form of task "cloning" is used for implementing retriggers, you can
ask James about this, afaik he just recreates a sub-graph with same task.payload.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum [:bhearsum] from comment #0)
> The current Buildbot <-> TC Bridge only supports injecting Buildbot
> BuildRequests after a Task has been created. This is what we want to do for
> the vast majority of things, but there's some edge cases (especially in the
> transition period) that will require us to create Tasks for Builds that
> originated in Buildbot (eg, rebuilds triggered through buildapi or automatic
> retries).

Clarification: automatic retries don't need tasks created, just new runs. This is already supported by the bridge.

> This probably means listening for additional events from Buildbot and
> creating tasks for them. One of the tricky parts is going to be how to give
> the Buildbot Build taskId and runId information. The way we're doing this
> for TC -> Buildbot jobs is through properties, but since the bridge won't be
> creating BuildRequests we can't use that strategy here.

runIds are no longer necessary in the buildbot properties, but task ids still are. I'm still not sure what to do about these...AFAIK we have no way of injecting task ids after a Build starts. Additionally, Jonas and I spoke on IRC and realized there's two different cases we need to handle here:
1) Task is already defined in a Task Graph somewhere, but start request comes through Buildbot (eg, push to mirrors Build of release automation). In this case the taskId _already_ exists, and we need it injected into the Build and for the bridge to claim the existing task.
2) Build starts in Buildbot but Taskcluster has no idea about it at all. This could happen if someone hits "force build" on a buildbot master. In this case we need a _new_ taskId to be injected into the Buildbot Build, and for the bridge to create and claim the task.

For both of these cases I _think_ we can accomplish this by requiring taskId in the Properties when jobs are started via some buildbot mechanism. For the first case, you'd be required to find the existing taskId and use that. For the second case you'd be required to generate your own and use that.

Chris, do you have any thoughts on this? My head is spinning a bit still, but it seems like this should work....

Comment 5

[[e-mail] (:bhearsum)]

This probably isn't going to get done in the first round of bridge work...and maybe not all. We've been talking more about not support job creation through Buildbot once scheduling has been migrated over. Leaving this bug open for now, but it may end up a WONTFIX.

Comment 6

[Chris Cooper [:coop] (he/him)]

We're going to do all scheduling in TC. Correct me if I'm wrong.