Closed Bug 637795 Opened 13 years ago Closed 13 years ago

Twice the number of required jobs run on my try push

Categories

(Release Engineering :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ehsan.akhgari, Assigned: lsblakk)

References

()

Details

Attachments

(2 files)

I pushed 8463cad783ca to the try server last night, and I got two runs of every job on my push.  This is a waste of resources, so I'm filing this for investigation.
Here's the logs for what happened.  This push was the only one affected.  The push before and after each got the right amount of builds.

From looking at the log there is a HgPoller failure and then a change is triggered followed by another one later and it looks like a hiccup which caused the the last changeset to stay in place for another round of polling.
Assignee: nobody → lsblakk
Status: NEW → ASSIGNED
Seems like there are non-ascii fortunes that could randomly cause this so one solution is to remove the fortunes from the email.  While fun, I'd rather turn it off than chase down the encodings.
Attachment #515989 - Flags: review?(catlee)
Attachment #515989 - Flags: review?(catlee) → review?(nrthomas)
Comment on attachment 515989 [details] [diff] [review]
Remove fortunes from try emails

My hovercraft full of eels is disappointed, but c'est la vie. 

I don't know this code very well at all, but seems strange that an HgPoller failure still found a change but didn't update the latest changeset var. The build submission mail runs in the same code where we parse any trychooser message right ?
Attachment #515989 - Flags: review?(nrthomas) → review+
The tryChooser code runs as a function in the Scheduler http://hg.mozilla.org/build/buildbotcustom/file/d806855cf1dc/misc.py#l824 whereas the email is generated in the ChangeNotifier http://hg.mozilla.org/build/buildbotcustom/file/d806855cf1dc/misc.py#l1659 

So perhaps it is possible that the failure could have left the tryChooser scheduler to carry on running but bailing when it reached the email?
Can't we just force the fortune text to be ascii?
sure, probably can, but as mentioned in comment #2 i'd rather turn it off than take the time to do that because it's quicker. anyone who wants to return them to the message should be sure to force ascii < 128
Status: ASSIGNED → RESOLVED
Closed: 13 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.

Attachment

General

Created:
Updated:
Size: