749108 - Thunderbird builds aren't being triggered by mozilla-* pushes

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P3)

Description

[Mark Banner (:standard8)]

I've pretty sure that we're not getting Thunderbird (comm-* branch) builds triggered by mozilla-* branch builds.

There was a landing in comm-central at 16:24 yesterday (24th) but a landing around midnigt (23:59) in mozilla-central, didn't trigger a second round of builds.

Comment 1

[[e-mail] (:bhearsum)]

John Hopkins poked me about this the other day and we came up with a potential way to do this: https://github.com/bhearsum/buildbotcustom/compare/mozilla:master...tb-scheduler

Needs misc.py integration still, to create the scheduler. The idea is that you'd instatiate a CommScheduler and pass config['moz_repo_path'] as the 'branch' and pass config['repo_path'] as the commBranch.

Needs testing, and a better name for CommScheduler, too.

Comment 2

[John Hopkins (:jhopkins)]

Other possibilities which would consume less build resources:

1) rate-limit Thunderbird builds that are based on mozilla-central pushes.  eg. no more than 1 every two hours.  Builds triggered by comm-central pushes would not be rate-limited.

2) add try-chooser syntax to allow specific mozilla-central revisions when building Thunderbird.  Could be paired with #1 above to narrow down bustage within the 2h window or be used on its own.  Allows people to bisect bustage by kicking off new builds at specific m-c revisions.

Thoughts on this?

Comment 3

[[e-mail] (:bhearsum)]

(In reply to John Hopkins (:jhopkins) from comment #2)
> Other possibilities which would consume less build resources:
> 
> 1) rate-limit Thunderbird builds that are based on mozilla-central pushes. 
> eg. no more than 1 every two hours.  Builds triggered by comm-central pushes
> would not be rate-limited.
> 
> 2) add try-chooser syntax to allow specific mozilla-central revisions when
> building Thunderbird.  Could be paired with #1 above to narrow down bustage
> within the 2h window or be used on its own.  Allows people to bisect bustage
> by kicking off new builds at specific m-c revisions.

We also talked about having a manifest in comm-central with a mozilla-central revision to pull. That's my preferred option of the three because it's a no-brainer on the buildbot side, and allows for better reproducibility.

Comment 4

[Mark Banner (:standard8)]

(In reply to Ben Hearsum [:bhearsum] from comment #3)
> We also talked about having a manifest in comm-central with a
> mozilla-central revision to pull. That's my preferred option of the three
> because it's a no-brainer on the buildbot side, and allows for better
> reproducibility.

Hmm, that's an interesting idea. If we could sketch it out a bit, i.e. commit messages, the revision location, etc, I could pass it around for feedback.

Comment 5

[[e-mail] (:bhearsum)]

(In reply to Mark Banner (:standard8) from comment #4)
> (In reply to Ben Hearsum [:bhearsum] from comment #3)
> > We also talked about having a manifest in comm-central with a
> > mozilla-central revision to pull. That's my preferred option of the three
> > because it's a no-brainer on the buildbot side, and allows for better
> > reproducibility.
> 
> Hmm, that's an interesting idea. If we could sketch it out a bit, i.e.
> commit messages, the revision location, etc, I could pass it around for
> feedback.

Commit messages won't factor in here at all. What we talked about last week was basically:
* Add build/mozilla-central.revision to comm-central, which will contain a mozilla-central revision in it
* Change client.mk/py to pull that mozilla-central revision instead of 'default' (except when MOZ_REVISION is set, so that release automation still works).

Basically, this would have you taking code drops from mozilla-central at specified times - and you could do it independently of comm-central changes. This could probably scripted too, if you want to make sure you get one every N hours or every N changes.

Comment 6

[Mark Banner (:standard8)]

That would seem reasonable, lets go for every 2 hours at an initial count. We may want it more frequently, but lets give it a try.

Comment 7

[John Hopkins (:jhopkins)]

standard8: I haven't heard that this is a big problem in practice and given our current emphasis on cost reduction, suggest that we wontfix this bug.  If you disagree, please reopen this bug.