Closed Bug 459213 Opened 16 years ago Closed 15 years ago

Dependent scheduler failed to fire after tagging for 3.1b1 release

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bhearsum, Unassigned)

References

(
URL
)

Details

(Whiteboard: [hg-automation])

Just like our 1.8 and 1.9 automation, Source and Build steps should be kicked off after Tagging completes. For some reason they did not automatically start. We need to investigate the cause of this and resolve it.
Whiteboard: [hg-automation]
OS: Mac OS X → All
Hardware: PC → All
Assignee: nobody → bhearsum
Priority: -- → P3
I'm seeing this on staging while doing a fake 3.1b2 release. I'm pretty sure it's a real issue now. Going to investigate.
Status: NEW → ASSIGNED
OS: All → Mac OS X
Priority: P3 → P2
Hardware: All → PC
The source of this problem is reconfig'ing while the upstream build is running. In the 3.1b1 release the master was reconfig'ed in the middle of tagging, which messed up the Dependent scheduler (or the upstream Scheduler, not sure). I've been able to reproduce this with small test factories on my local machine. Note that this only happens when either the upstream Scheduler or the downstream Dependent scheduler has changed. Because of the way our buildbot configs are managed (probably because the release_* stuff is imported into the main master) Buildbot always thinks the schedulers have changed. I'm not entirely sure what the fix for this is, and I'm inclined to WONTFIX or morph this bug. Certainly, the fix is either an upstream Buildbot patch or a complete revamp of our configs. Either way I'm going to file an upstream bug.
(In reply to comment #2) > The source of this problem is reconfig'ing while the upstream build is running. > Good to know, on Monday I hit the same problem with the l10n stuff since I was doing so many reconfigs for hour and minute changes
It looks like http://buildbot.net/trac/ticket/35 may be the upstream ticket for this. We should look at taking this on if we want it fixed soon. I'm going to toss this bug back in the pool for now because it's not a *major* issue for release automation. It might bite us more often for l10n builds, though.
Assignee: bhearsum → nobody
URL: http://buildbot.net/trac/ticket/35
Priority: P2 → P3
No longer blocks: 433930
Component: Release Engineering → Release Engineering: Future
Upstream ticket has been fixed. We'll get it next time we upgrade Buildbot.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.