Closed Bug 1165431 Opened 5 years ago Closed 5 years ago

runId is wrong in buildbot properties for rebuilds of buildbot bridge jobs


(Release Engineering :: General, defect)

Not set


(Not tracked)



(Reporter: bhearsum, Unassigned)



(Whiteboard: [bbb])

Buildbot gets the runId of a Task through a sourcestamp property. This means that it gets set when the Build is created. This is fine for the first attempt of a task, because the sourcestamp properties are injected prior to the Build starting. For rebuilds, this is not the case - they generally will create a Build before the bridge is even aware that they're rebuilding, so they get the original runId in the properties....which is wrong.

I'm not really sure how to fix this with the current design...I can't think of any way to make sure a Build gets the proper run id if the buildbot bridge is in charge of setting it -- there's no way to have the bridge run some code prior to a rebuild starting.

One way of working around this may be to stop setting runId in properties and force anything running as part of a Build to use the latest runId. This might have other issues...
I thought about this some more this morning and dug into the Buildbot code to verify the way in which sourcestamp properties work (changes to them are ignored after the Build starts, like I thought). I can't come up with any other ideas, so I think we should move forward with ripping out runId from the properties, and making consumers retrieve it when they need it. If there are any situations where we have multiple active Builds for the same BuildRequest, or where anything other than the latest Build for a BuildRequest is the one that satifies it, there will be issues with this -- but I think we can deal with those as they come up.

Mike, I think you're the only person that could possibly be using the runId that's currently in the properties. AFAICT nothing in is using it though. Do you know of anything that *does* use the one from the properties? If not, this bug is easy....
Flags: needinfo?(mshal)
Mike and I talked about this on IRC. He reminded me that runId isn't present in any production jobs already, because the bridge isn't scheduling them. That means it's safe to remove! I did this in

It's worth noting that bridge is still tracking the runId for its own purposes -- it needs it to resolve tasks, create artifacts, etc.
Closed: 5 years ago
Flags: needinfo?(mshal)
Resolution: --- → FIXED
Whiteboard: [bbb]
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.