If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Status

Release Engineering
General
P1
blocker
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: philor, Assigned: nthomas)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
See, for instance, https://tbpl.mozilla.org/?tree=Mozilla-Inbound where the tip push hasn't scheduled builds, or https://tbpl.mozilla.org/?tree=Try where various builds have finished, but not scheduled the tests they should have.

Trees are closed.
(Assignee)

Updated

6 years ago
Assignee: nobody → nrthomas
Status: NEW → ASSIGNED
Priority: -- → P1
(Assignee)

Comment 1

6 years ago
Scheduling is working again now. More details to follow.
(Assignee)

Comment 2

6 years ago
There were two problems here

* it looked like builds were not started on inbound because the push to inbound was right on top of the reconfig, and the change got dropped on the floor (bug 675558 gets rid of an exception but changes can still be lost)

* tests were not being scheduled because that master got wedged trying to process all the changes since larch, jaegermonkey, and devtools were last enabled. More on that with an attachment ....
Blocks: 723479
(Assignee)

Comment 3

6 years ago
Created attachment 627825 [details]
List of deleted schedulers

This is the schedulers I deleted while the test master was shutdown (a kill -9 was needed because the process was blocked on a futex). It was derived from using a hacked dump_master.py to get the list of active test schedulers, then looking in the buildbot_schedulers db to see which had processed a change less than 1300000.
(Assignee)

Updated

6 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 6 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.