Closed Bug 1299078 Opened 7 years ago Closed 7 years ago

Nightlies not being generated


(SeaMonkey :: Release Engineering, defect)

Not set


(Not tracked)



(Reporter: ewong, Assigned: ewong)



(1 file, 5 obsolete files)

There are currently no nightlies.

Basically due to a sequence of events, our nightlies have failed to 

Event #1: was

Event #2: master had a hiccup that required restart

After 'fixing' some db items, the scheduler came and went and still
didn't run the builds.

So..  once again, thanks to nthomas' hint, I came across the following

which is :

lastGoodRev() from
returns None because there hasn't been a good Nightly build in 24hrs. 

So it continues to:

which checks if l10nBranch.  since enable_l10n has been disabled,
this is false.

Therefore, lastGoodFunc() returns None.

So, my current idea is to actually remove lines #292 and 293 so that
it goes to line #297.

288       if not triggerBuildIfNoChanges:
289                if l10nBranch:
290                    if (start-lastL10nChange) > (24*3600):
291                        return None
292                else:
293                    return None
295            # Couldn't find a good revision.  Fall back to using the latest
296            # revision on this branch
297            c = lastChange(db, t, branch)
298            if c:
299                rev = c.revision
300            log.msg("lastChange returned %s" % (rev))

and looking through the ssFunc,  I realized that given
"triggerBuildIfNoChanges=False", the system goes to
Attached patch [buildbotcustom] proposed patch (obsolete) — Splinter Review
*n-i myself to remind me to ask Callek for review
Assignee: nobody → ewong
Flags: needinfo?(ewong)
over irc, :nthomas also suggested we use lastRevFunc instead of lastGoodFunc.
at least it will avoid this problem.
was looking at production branch and thought we had lastRevFunc.  
We don't, so adding to
Attachment #8786259 - Attachment is obsolete: true
Flags: needinfo?(ewong)
Summary: Nightlies scheduling failing. → Nightlies not being generated
didn't finish comment #0 apparently :(

"...the system goes to
since l10nBranch is false.  so it returns None.
Attached patch [buildbotcustom] (wip) patch (obsolete) — Splinter Review
this patch actually unhorks the nightly.  but it's still a wip.
Attachment #8786262 - Attachment is obsolete: true
Attachment #8786676 - Flags: review?(bugspam.Callek)

the most recent patch forces the nightly to run.

however, it still needs some fixes as within the not forceBuildLastChange 
condition, it has:

  later_rev = getLatestRev(db, t, branch, rev, last_built_revs[0])

I just set it to an arbitrary value (i.e. the 1st item in the list).
I took the lastRevFunc() and getLastBuiltRevisions() from moco's
buildbotcustom code; but adapted it to our code.

Though all in all, I'm still unhappy that it's just a hack to get things

I'm wondering if we should just use the lastChange revision and
build against that for the nightly?
Attached patch [buildbotcustom] wip patch (obsolete) — Splinter Review
Attachment #8786676 - Attachment is obsolete: true
Attachment #8786676 - Flags: review?(bugspam.Callek)
Attachment #8787085 - Flags: feedback?(bugspam.Callek)
Will go for a post-land-review and will push fixes after.  Currently the
manually-applied-patches-to-fix-misc-builds needs to be applied properly.
Attachment #8786255 - Attachment is obsolete: true
Attachment #8787085 - Attachment is obsolete: true
Attachment #8787085 - Flags: feedback?(bugspam.Callek)
Attachment #8798292 - Flags: review?(bugspam.Callek)
(In reply to Edmund Wong (:ewong) from comment #9)
> ac4f92670349e34455ac9ee6fcdf7b795c2505e7
> Bug 1299078 - Use lastRevFunc instead of lastGoodFunc.

backing this out.
Attachment #8798292 - Attachment description: [buildbotcustom] proposed patch (v4) → [buildbotcustom] proposed patch (v4) [checked-in]
Comment on attachment 8798292 [details] [diff] [review]
[buildbotcustom] proposed patch (v4) [checked-in]

considered fixed.
Attachment #8798292 - Flags: review?(bugspam.Callek)
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.