Closed Bug 413906 Opened 17 years ago Closed 15 years ago

try server often lies about the number of pending builds

Categories

(Release Engineering :: General, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Unassigned)

References

Details

(Whiteboard: [tryserver])

This happens because of the way MozillaTryProcessing re-injects changes into the queue. There's got to be a better way to do this.
Priority: -- → P2
I spent some time reading Buildbot code today and I believe the best way to implement this is going to depend on ClientMkSource. The 'buildbot try' command supports attaching a diff as of 0.7.6; we can simply use this instead of sendchange. However, these patches get applied in the Source class which we cannot use at this time. I tried some different hackery to get the pending builds working again (various things BuildMaster.submitBuildSet()), but it remains broken. I'm filing a bug on ClientMkSource and intend to get that working.
Depends on: 414031
Priority: P2 → P3
Tossing this back into the queue for now.
Assignee: bhearsum → nobody
Status: ASSIGNED → NEW
Mass change of target milestone.
Target Milestone: --- → Future
Component: Try Server → Release Engineering
Product: Webtools → mozilla.org
QA Contact: try-server → release
Target Milestone: Future → ---
Version: Trunk → other
Component: Release Engineering → Release Engineering: Future
This is still true, sadly. MozillaTryProcessing lives on.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
This will get fixed as part of try-as-a-branch
Depends on: 520227
Whiteboard: [tryserver]
Priority: P3 → P5
And now try-as-branch is live, so closing.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.