We'll want to have a mozharness script for android builds. Based on the work that dustin has done so far, this looks like it'll either be a simple android_build.py, or possibly just reuse fx_desktop_build.py.

The easy part - we just need to turn off l10n-check in the automation steps. The defaults are fine for the rest.

buildbot-configs changes to turn on mozharness+mach for android in 40+

mozharness part 1 - configs for building android. Since the automation steps are driven by the mozconfigs, we can re-use fx_desktop_build. The only annoying thing here is how the build variants are specified - if there is a better solution there, I'm all for it.

mozharness part 2 - support for multil10n.py. Android nightlies do both an en-US build and a multilocale build, where the en-US build is uploaded to an 'en-US/' subdirectory on FTP (the changes to query_mach_build_env() are to support this subdirectory). This patch adds support for a multi-l10n action in the base build script, but it's effectively unique to android builds. In order to re-use the existing multi-locale configs, I added a wrapper config (android-mozharness-build.json) which modifies the work_dir and such to reflect mozharness' directory layout instead of buildbot's. We can't change the multi-locale configs directly since they are shared by the separate l10n jobs.

Comment on attachment 8599429 [details] [diff] [review] bb-android.patch Review of attachment 8599429 [details] [diff] [review]: ----------------------------------------------------------------- Looks straight-forward to me.

Comment on attachment 8599430 [details] [diff] [review] android Review of attachment 8599430 [details] [diff] [review]: ----------------------------------------------------------------- Also looks fair, unfortunately I'm not away of a better way to specify the various build variants are specified (looks like what you did is par for the course).

Comment on attachment 8599433 [details] [diff] [review] android-l10n Review of attachment 8599433 [details] [diff] [review]: ----------------------------------------------------------------- Aside from being sad at the complexity of basebuilder.py, I don't see any problems mh wise; but I'm not well versed in android or multi-locale builds. Interested to see if Dustin has any change requests after he applies this to his work.

Comment on attachment 8599430 [details] [diff] [review] android https://hg.mozilla.org/build/mozharness/rev/2bf07a03f390

Comment on attachment 8599433 [details] [diff] [review] android-l10n https://hg.mozilla.org/build/mozharness/rev/8e5ae5da36c1

I ran these in my docker container (in progress in bug 1125973), and got 20:47:09 INFO - abs_src_mozconfig: /home/worker/workspace/build/src/mobile/android/config/mozconfigs/android/nightly 20:47:09 FATAL - "abs_src_mozconfig" path could not be determined. Please make sure it is a valid path off of "abs_src_dir" can you help figure out what that might mean? Desktop builds using the same container worked (mostly; tests failed, but I think that was a missing Xvfb).

(In reply to Dustin J. Mitchell [:dustin] from comment #12) > I ran these in my docker container (in progress in bug 1125973), and got > > 20:47:09 INFO - abs_src_mozconfig: > /home/worker/workspace/build/src/mobile/android/config/mozconfigs/android/ > nightly > 20:47:09 FATAL - "abs_src_mozconfig" path could not be determined. Please > make sure it is a valid path off of "abs_src_dir" > > can you help figure out what that might mean? Desktop builds using the same > container worked (mostly; tests failed, but I think that was a missing Xvfb). It looks like the base "android" build was removed in bug 1126360. I setup the mozharness builds to match those in buildbot, and we still have an "android" in there, though it appears to be no longer used. Can you try to pass in a --custom-build-variant-cfg parameter and see if that works? Here are the possible values for android: + '--custom-build-variant-cfg', 'api-9', + '--custom-build-variant-cfg', 'api-11', + '--custom-build-variant-cfg', 'x86', + '--custom-build-variant-cfg', 'debug', + '--custom-build-variant-cfg', 'api-9-debug', + '--custom-build-variant-cfg', 'api-11-debug', (In the buildbot+mozharness case, these are passed in from buildbot). Perhaps the default android variant should be api-9 since plain "android" no longer exists?

great, thanks!

Comment on attachment 8599429 [details] [diff] [review] bb-android.patch https://hg.mozilla.org/build/buildbot-configs/rev/f895d6aaa604

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

Comment on attachment 8599429 [details] [diff] [review] bb-android.patch The buildbot-configs change was backed out because neither mozharness nor mach are able to set packageUrl correctly.

This stores the value of PACKAGE in mach_build_properties.json, and uses it to set packageUrl. The packageFilename parameter is needed since the same logic exists in mozharness for taskcluster uploads. In particular, this lets us be explicit with which file is the package, rather than assuming it's any .zip/.bz2/.apk that isn't in an exclusion list, which is rather error prone: http://mxr.mozilla.org/build/source/buildbotcustom/process/factory.py#227

With packageFilename from mach_build_properties.json, we can fixup the packageUrl override for S3 uploads in mozharness. This should solve the issue that caused the android switchover to get backed out.

Comment on attachment 8605982 [details] [diff] [review] packageName Review of attachment 8605982 [details] [diff] [review]: ----------------------------------------------------------------- Ship it!

Comment on attachment 8605982 [details] [diff] [review] packageName https://hg.mozilla.org/build/mozharness/rev/2fdb3d55efa0

Comment on attachment 8599429 [details] [diff] [review] bb-android.patch https://hg.mozilla.org/build/buildbot-configs/rev/b75f5cfeebc6 I bumped the version 40 check to version 41 because releases moved since then.

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

Did this intentionally change the destination of android builds from http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/ to http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ ?

(In reply to Bob Clary [:bc:] from comment #26) > Did this intentionally change the destination of android builds from > http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/ to > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ ? Nope, not intentional. Looks like I missed setting a variable in the mozharness configs - I'll test out a fix & hopefully get a patch out today.

Sets stage_product to 'mobile' for android builds. This puts them in the right subdirectory, instead of the default 'firefox'.

Comment on attachment 8609492 [details] [diff] [review] android-mobile https://hg.mozilla.org/build/mozharness/rev/f856bdc62b68

Note this still changed the urls to the builds. Now the build is located in the en-US subdirectory: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android-api-9/1432570281/en-US/ while before the en-US subdirectory wasn't used: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android-api-9/1432218258/ Again, if this is intentional I can live with it, but it does impose a tax on any consumers of mobile builds. We are already having to plan for the move to s3 at some point and these paper cuts simply add to the burden.

FYI, https://hg.mozilla.org/build/buildbot-configs/rev/b75f5cfeebc6 disabled mozharness for desktop builds on aurora and beta. jlund tells me that we didn't actually want that on beta, but aurora is a regression.

(In reply to Michael Shal [:mshal] from comment #18) > Created attachment 8605980 [details] [diff] [review] > 0001-Bug-1155349-set-packageFilename-in-mach-properties.patch Since this is now required to build on try, can we land it on every single active release branch, so we don't have to have the method for testing a backport to aurora be "push aurora to try, wait, discover that all your builds burned, ask on #developers, be told you have to stick bd6fb3d49f40 in your patch queue, push to try again"?

as nick mentioned, https://bug1155349.bugzilla.mozilla.org/attachment.cgi?id=8599429 disables m-a mh desktop builds. This is because desktop_mozharness_builds_enabled is branch wide config item. We have enabled m-a as a mozharness 'able' build branch already so anything that has 'mozharness_desktop_build' (a platform item), will use mozharness. I think the solution here is to remove the platform level item for android builds that are less than m-c http://people.mozilla.org/~jlund/reverse_the_disabling_of_mh_desktop_builds.patch fwiw, the issue, unrelated to this bug, that caused m-b desktop builds to use mh will be addressed here: https://bugzil.la/1155349 builderlist diff of this patch: http://people.mozilla.org/~jlund/reverse_the_disabling_of_mh_desktop_builds.patch

> fwiw, the issue, unrelated to this bug, that caused m-b desktop builds to > use mh will be addressed here: https://bugzil.la/1155349 derp, I mean https://bugzil.la/1144475

Comment on attachment 8610340 [details] [diff] [review] re-enables_mh_desktop_builds_on_m-a.patch >diff --git a/mozilla/config.py b/mozilla/config.py >index d40ad0b..7c44ac9 100644 >--- a/mozilla/config.py >+++ b/mozilla/config.py >@@ -3008,7 +3008,9 @@ for name, branch in items_at_least(BRANCHES, 'gecko_version', 39): > for name, branch in items_before(BRANCHES, 'gecko_version', 41): > for platform in branch['platforms'].keys(): > if 'android' in platform: >- branch['desktop_mozharness_builds_enabled'] = False >+ # we don't want to disable the branch level item: "desktop_mozharness_builds_enabled" >+ # we do wnat to remove the platform level item: "mozharness_desktop_build" wnat -> want

Comment on attachment 8610340 [details] [diff] [review] re-enables_mh_desktop_builds_on_m-a.patch thanks and updated: remote: https://hg.mozilla.org/build/buildbot-configs/rev/c1256cb8daad

Since the multi-l10n step only happens on nightly builds, we should only create the en-US subdirectory on nightlies. This makes it so we only pay attention to the multi_locale config option on nightly builds.

Comment on attachment 8610818 [details] [diff] [review] android-nightly-enUS https://hg.mozilla.org/build/mozharness/rev/1f23c3f19992

Removing leave-open keyword from resolved bugs, per :sylvestre.