Nick Thomas [:nthomas] (UTC+12) Reporter
	Description • 9 years ago

... maybe!

mozharness desktop builds will ride to Beta when we merge at the end of March. The code for that is at http://hg.mozilla.org/build/buildbot-configs/file/bd1582014509/mozilla/config.py#l2886

Then we'll have a point of difference as the release automation builds will still be using buildbot factories, which might result in bustage when the release automation runs. catlee suggested disabling mozharness desktop and using the existing buildbot factories for dep builds. That should result in bustage showing up after the merge, which is less time-critical.

To make the transition to mozharness we could work on converting the existing automation, or wait for build promotion to achieve the same result.

Comments ?

	bhearsum@mozilla.com (:bhearsum)
	Comment 1 • 9 years ago

+1, this seems very sensible to me. Has anyone scoped out or started to look at moving release builds?

	Chris AtLee [:catlee]
	Comment 2 • 9 years ago

We haven't scoped it out yet. It seems like a lot of work, but maybe I'm wrong :) I'm hoping build promotion saves us!

	Jordan Lund (:jlund) Assignee
	Comment 3 • 9 years ago

iiuc keeping mh builds locked to m-c + m-a shouldn't be too bad. anything that has been riding the trains and only implemented in mh, will get lost in the cosmos when it hits beta.

However, I don't think there is anything special on aurora right now so holding back one cycle doesn't seem like the worst thing. Maybe just some fallout. ReleaseBuildFactory is not too bad in terms of code: extra uploading/updating steps but where there will be a time sink is in cross referencing the edge cases.

	Jordan Lund (:jlund) Assignee
	Comment 4 • 9 years ago

this patch will have to land with the buildbot-config gecko version bump patch: https://bug1123369.bugzilla.mozilla.org/attachment.cgi?id=8580308

	Jordan Lund (:jlund) Assignee
	Comment 5 • 9 years ago

Comment on attachment 8585545 [details] [diff] [review]
150319_bug_1144475_lock_mh_builds_on_m-a_bbot-cfgs.patch

thanks. over irc we agreed it would be better to be more explicit about this by using branch names so we don't have to do this again on next merge if MRF is not ported yet.

on default: https://hg.mozilla.org/build/buildbot-configs/rev/51de96203f9c

	Jordan Lund (:jlund) Assignee
	Comment 6 • 9 years ago

I'll leave this open to do follow up path (comment 5)

	Jordan Lund (:jlund) Assignee
	Comment 7 • 9 years ago

In production: https://hg.mozilla.org/build/buildbot-configs/rev/51de96203f9c

	Jordan Lund (:jlund) Assignee
	Comment 8 • 9 years ago

this patch will apply on top of: https://bugzilla.mozilla.org/show_bug.cgi?id=1155349#c33

it uses a static gecko version of m-b so we don't run into this issue on next merge ;)

builderlist diff of this patch applied on top of 1155349#c33: http://people.mozilla.org/~jlund/disables_m-b_mh_desktop_builds-builderlist.diff

builderlist diff of both patches: http://people.mozilla.org/~jlund/re-enables_m-a_desktop_mh_builds_and_disables_m-b_desktop_builds-builderlist.diff

	bhearsum@mozilla.com (:bhearsum)
	Comment 9 • 9 years ago

Comment on attachment 8610341 [details] [diff] [review]
disables_mh_desktop_builds_on-b.patch

Review of attachment 8610341 [details] [diff] [review]:
-----------------------------------------------------------------

::: mozilla/config.py
@@ +3002,1 @@
>  # enable mozharness desktop builds across m-c and related branches

r+, but this comment needs updating.

	Jordan Lund (:jlund) Assignee
	Comment 10 • 9 years ago

Comment on attachment 8610341 [details] [diff] [review]
disables_mh_desktop_builds_on-b.patch

thanks and updated:

remote:   https://hg.mozilla.org/build/buildbot-configs/rev/2e60206c8b36