Closed
Bug 991707
Opened 11 years ago
Closed 9 years ago
Don't generate nightly builds on a tree if no new changes have landed since the previous nightly
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: emorley, Assigned: nthomas)
References
Details
(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2578] [capacity])
Attachments
(2 files)
1.17 KB,
patch
|
rail
:
review+
nthomas
:
checked-in+
|
Details | Diff | Splinter Review |
3.11 KB,
patch
|
rail
:
review+
nthomas
:
checked-in+
|
Details | Diff | Splinter Review |
(In reply to Phil Ringnalda (:philor) from bug 991476 comment #0)
> Last week, we switched the default for nightlies from building on the last
> good rev, which also switched them from looking at whether or not a nightly
> had been built on the last rev, to just building on the tip.
>
> Since then, we've built six pointless nightlies on the Ionmonkey tree, and
> triggered six full sets of pointless mostly-unrunnable tests on it. The fact
> that we're out $60 for that is minimal, compared to the fact that we're out
> the use of those slaves during a critical time of the day.
We should make sure we don't build new nightlies if there were already ones on that rev (l10n repo changes excepted, for repos where we do non-en-us builds too).
Assignee | ||
Comment 2•11 years ago
|
||
lastRevFunc looks up the last revision build for builders belonging to the current scheduler, and has support to not build if that's tip, we just default to not using that for nightlies. This gives us the option to.
Attachment #8436574 -
Flags: review?(rail)
Assignee | ||
Comment 3•11 years ago
|
||
This uses triggerBuildIfNoChanges=False for oak and ux branches, and leaves alone central/aurora/b2g-*. This and the buildbotcustom patch pass checkconfig on a build scheduler master, but I haven't figured out any way to test in more depth than that.
Assignee | ||
Comment 4•11 years ago
|
||
I made my changes based on oak example in bug 1019976, but if we could also do this everywhere except the active b2g branch(es).
Updated•11 years ago
|
Attachment #8436574 -
Flags: review?(rail) → review+
Comment 5•11 years ago
|
||
Comment on attachment 8436575 [details] [diff] [review]
[buildbot-configs] Project branches only build nightlies when code changes
... .... .. .--. .. -
Attachment #8436575 -
Flags: review?(rail) → review+
Assignee | ||
Comment 6•11 years ago
|
||
Comment on attachment 8436574 [details] [diff] [review]
[buildbotcustom] Add config to override triggerBuildIfNoChanges for nightlies
https://hg.mozilla.org/build/buildbotcustom/rev/9a67b2c5288f
Attachment #8436574 -
Flags: checked-in+
Assignee | ||
Comment 7•11 years ago
|
||
Comment on attachment 8436575 [details] [diff] [review]
[buildbot-configs] Project branches only build nightlies when code changes
https://hg.mozilla.org/build/buildbot-configs/rev/5160e18a75fc
Attachment #8436575 -
Flags: checked-in+
Comment 8•11 years ago
|
||
In prod with reconfig on 2014-06-12 10:46 PT
Assignee | ||
Comment 9•11 years ago
|
||
This is working on Oak and UX.
Ed/philor, would you like to extend this to other branches ? We have nightlies enabled on m-c, m-a, m-esr24, m-b2g28_v1_3, m-b2g28_v1_3t, m-b2g30_v1_4. IIRC QA wants b2g to always build, but esr24 is probably idle enough that it's worth changing.
Comment 10•11 years ago
|
||
I can't remember where the "but build it anyway if there were l10n changes even if there weren't code changes" comes in to know whether it's safe to do this to m-a without messing that up, but I'd think esr24 has been l10n frozen for quite some time and it'd be safe there no matter what.
Reporter | ||
Comment 11•11 years ago
|
||
I'd like to do this everywhere where it's possible, as long as the l10n feature that philor mentioned isn't regressed :-)
Updated•10 years ago
|
Whiteboard: [capacity] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2578] [capacity]
Comment 12•10 years ago
|
||
So I have seen this problem over the weekend for the Aurora builds. No code changes have been landed between Saturday and Sunday but we got a completely identical build on Sunday.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/08/2015-08-15-00-40-04-mozilla-aurora/firefox-42.0a2.en-US.linux-i686.txt
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/08/2015-08-16-00-40-12-mozilla-aurora/firefox-42.0a2.en-US.linux-i686.txt
Given that a lot of tests are reporting to treeherder those days, it will cause confusion. Especially with tools like our firefox-ui-tests which run on pulse messages and then report multiple times to the same changeset. An example you can see here:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-aurora&filter-job_group_symbol=Ff&filter-job_group_symbol=Fr&filter-job_group_symbol=Fu&exclusion_profile=false
This bug is lingering around for the last year, so I wonder if we can finally finish it up? Nick, what's left to do here to get it also working for the other branches?
Flags: needinfo?(nthomas)
Assignee | ||
Comment 13•9 years ago
|
||
Did you see comment #10 ? There's a valid use case for aurora, where l10n changes should generate new nightly builds even if gecko hasn't changed.
Flags: needinfo?(nthomas)
Sure but that only repacks the en-US build for the changed locales. If en-US has not been changed ideally no new build would be necessary. But I assume the l10n repack scripts want a build of the same build id and that's why we took the route to build them all? Out ouf interest what happens if only a single locale has been changed? Do we build all, or only en-US and that locale?
Assignee | ||
Comment 15•9 years ago
|
||
It's just how the scheduling was implemented in buildbot. And en-US nightly triggers l10n nightlies, with no provision to just do l10n in some cases. I'm not sure if we are considering all locales at this point.
Assignee | ||
Comment 16•9 years ago
|
||
Current state:
ash only changes
oak only changes
mozilla-esr38 only changes
mozilla-central every time
mozilla-aurora every time
mozilla-b2g37_v2_2 every time
mozilla-b2g37_v2_2r every time
mozilla-b2g44_v2_5 every time
b2g-ota every time
comm-central every time
comm-aurora every time
comm-esr38 every time
b2g is a special case, and you could argue that Thunderbird is too (AFAIK comm builds don't track if gecko changed).
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•