Closed Bug 1156305 Opened 10 years ago Closed 8 years ago

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

Categories

(Release Engineering :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bhearsum, Unassigned)

References

Details

(Whiteboard: [bbb])

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.
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.
(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.
> 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.
(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....
Flags: needinfo?(catlee)
No longer blocks: bbb
Whiteboard: [bbb]
Depends on: 1164455
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.
Assignee: bhearsum → nobody
Flags: needinfo?(catlee)
We're going to do all scheduling in TC. Correct me if I'm wrong.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.