we had a issue on the trees where a checkin on mozilla-inbound (and so a later merge to m-c) caused a bustage on all device builds on mozilla-central. This change now got backedout in https://tbpl.mozilla.org/?rev=735a648bca0d however there was no way to detect this bustage before the merge because we don't run device builds on mozilla-inbound. maybe we should run device builds on mozilla-inbound at least for pgo runs (that we use for merges) to detect such issues sooner
Adding device builds to mozilla-inbound will be a considerable jump in the CPU usage per push. Can we use social engineering to solve this problem instead ? eg, updating libraries used by b2g should land on b2g-inbound.
Sure, all we'd have to do then is to change b-i to be m-i, adding WinXP and Win7 and 10.7 and whatever else I've forgotten that we don't run on b-i.
(In reply to Nick Thomas [:nthomas] from comment #1) > Adding device builds to mozilla-inbound will be a considerable jump in the > CPU usage per push. Can we use social engineering to solve this problem > instead ? eg, updating libraries used by b2g should land on b2g-inbound. Like philor said, that would basically move most of core Gecko development over to b-i, which doesn't seem like the desired outcome. And for what's a pretty rare situation (this is the first instance I can recall of B2G device image bustage where the emulator builds were fine). Can we compromise and just build one device image per-push on inbound, like Hamachi? It would have caught this bustage without running the full gamut.
Created attachment 8383230 [details] [diff] [review] enable periodic device builds on m-i This enables periodic device builds on m-i for all the devices we have on b-i. It also switches hamachi user builds to periodic rather than per-push (as per jsmith on irc) It also enables hamachi builds on larch (bug 977718)
buildbot-configs patch is merged and live in production! :)