Use a disposable branch to produce builds with full beta branding, mozconfig options, "pretty naming", beta signing keys, etc. Run those builds when code lands in the repo, and ensure tests are triggered. For comparison of test results, it may be helpful to run the beta builds in parallel with existing builds. Complete mar files should created for each build but not partials. XULRunner SDKs will happen here too.

Grabbed Date for this, bug 1089701 to recreate the repo after the merge.

This will get me the same set of builders and testers as mozilla-beta has, but using mozharness for builds. Will still uses the dep certs, and doesn't actually do pgo, but I'll get those later.

Comment on attachment 8553320 [details] [diff] [review] [buildbot-configs] Date setup 1.0 woooooo!!!!

Comment on attachment 8553320 [details] [diff] [review] [buildbot-configs] Date setup 1.0 https://hg.mozilla.org/build/buildbot-configs/rev/3bfb8518160f

buildbot-config patch(es) are live in production

First builds - https://treeherder.mozilla.org/#/jobs?repo=date&revision=1d3c24b896a1 Green: * talos and webplatform on all platforms except mac, which fails to encode spaces into %20 in urls (dmg+crash symbols, also tests.zip but not needed for talos). win32 unexpectedly works, because it uses the .zip file which doesn't have pretty naming; neither does the crashreporter symbols * everything on win64 except JP, because it doesn't use pretty naming Failing: * mochitest/reftest/crashtest/etc - incorrectly computing jsshell url, eg http://ftp.mozilla.org.proxxy1.srv.releng.usw2.mozilla.com/pub/mozilla.org/firefox/tinderbox-builds/date-linux/1422324743/jsshell-0.zip, which should end jsshell-linux-i686.zip. We're passing in pretty named files which don't contain a platform, and query_jsshell_url() at http://hg.mozilla.org/build/mozharness/file/ccc3f9f479d4/mozharness/mozilla/testing/testbase.py#l120 relies on it being present.

\o/ do these tests require the jsshell, or can we ignore this here?

I tried turning off the jsshell download, and it turns out only jittest needs it. The other mochitests went green.

https://hg.mozilla.org/build/buildbot-configs/rev/c6ae16127e65 bumps the gecko version to 37 on date.

We reverted to using non-pretty names, and will rename files between them being produced and being stashed in the candidates directory. This implies some munging off checksums files and resigning. Complete mar files are happening in each build, although they don't show up in tinderbox-builds because post_upload.py drops them. They do end up in TC as artifacts. SDK files are being produced and uploaded after porting bug 1137000, with some tweaks. At this point I need to sort through the patches and figure out what can land, and what remains in date only.

One thing of note - current release builds clobber the working directory at the top of every job, while on-push builds do not. We could clobber every depend build on every beta/release and put up with the performance hit, or drop that requirement. Since speed is the point of moving to promotion it deserves serious consideration, but I'm planning that we do that as a followup.

Bringing over a little of my setup from a user repo * sets the mozconfig for on-push builds to be the on used for release builds on the beta branch * sets ENABLE_RELEASE_PROMOTION in en-US builds, which changes some variables in mozconfigs to follow (uploading symbols and creating the SDK in each build)

(In reply to Nick Thomas [:nthomas] from comment #11) > One thing of note - current release builds clobber the working directory at > the top of every job, while on-push builds do not. We could clobber every > depend build on every beta/release and put up with the performance hit, or > drop that requirement. Since speed is the point of moving to promotion it > deserves serious consideration, but I'm planning that we do that as a > followup. I honestly can't remember why we clobber. I know we used use -j1 for release builds because we were paranoid about ||ization doing something bad, and this feels like it's in a similar vein. Personally, I'd be okay getting rid of it. We can always add it back in if we realize it's important later...

Comment on attachment 8585407 [details] [diff] [review] [mozharness] Setup 2 Review of attachment 8585407 [details] [diff] [review]: ----------------------------------------------------------------- ::: configs/builds/branch_specifics.py @@ +114,5 @@ > + 'date': { > + 'enable_release_promotion': 1, > + 'platform_overrides': { > + 'linux': { > + 'src_mozconfig': 'browser/config/mozconfigs/linux32/beta', Once release promotion is the only supported way to build on branches like this it may be better to just change the "nightly" mozconfigs rather than maintain separate names. I wonder how much of the contents of release style mozconfigs we want to bring all the way back to opt builds on central/aurora, too. This certainly seems like the best thing for now while we need to support both styles. Sidenote: This made me think that mozconfig comparison tests will be going away in a build promotion world...I hope I'm right about that!

Comment on attachment 8585407 [details] [diff] [review] [mozharness] Setup 2 https://hg.mozilla.org/build/mozharness/rev/2dd0966af501

(In reply to Ben Hearsum [:bhearsum] from comment #14) > Once release promotion is the only supported way to build on branches like > this it may be better to just change the "nightly" mozconfigs rather than > maintain separate names. I wonder how much of the contents of release style > mozconfigs we want to bring all the way back to opt builds on > central/aurora, too. This certainly seems like the best thing for now while > we need to support both styles. > > Sidenote: This made me think that mozconfig comparison tests will be going > away in a build promotion world...I hope I'm right about that! Possibly. I think we'll want a slightly different kind of promotion on nightly+aurora, eg dep builds to nightlies. There will probably be some branding differences, but maybe those are in confvars.sh and handled at merge time. Getting rid of the mozconfig comparisons would be great.

mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/production

Date is up and running, with the following caveats * complete.mar files aren't on ftp, but are in taskcluster * population of the candidates dir/bucket will be done separately, it's closely related to the netapp -> S3 project in Q2 * the patches for complete mar and sdk need to be extracted and landed on m-c/m-a/m-b if they can be made safe, see bug 649485 and bug 1142231

Is this done and/or superceded by bug 1178324?

Superceded, lets say this was the initial setup work.