Add the b2g/config/aries/config.json configure file to enable mozharness building of the aries device.

/r/5659 - Bug 1134722: Add b2g_bumper configuration for aries device. Pull down this commit: hg pull review -r 867466111f40811e505b326731b965738731063a

/r/5663 - Bug 1134722: Add aries building config files. Pull down this commit: hg pull review -r 2f35c150df788d9ebb6c28c12462f576af2eadc9

Comment on attachment 8579632 [details] MozReview Request: bz://1134722/wcosta https://reviewboard.mozilla.org/r/5661/#review4661 ::: b2g/config/aries/releng-aries.tt (Diff revision 1) > +"filename": "backup-flame.tar.xz", Are you sure you need backup-flame.tar.xz here? The flame tooltool manifest has it and also references it in config.json, while you have a 'backup-aries.tar.xz' listed there. ::: b2g/config/aries/config.json (Diff revision 1) > + "additional_source_tarballs": ["backup-aries.tar.xz"], I think you either need to add backup-aries.tar.xz to the tooltool manifest, or if you don't need this zip file, maybe this line needs to go away.

Comment on attachment 8579632 [details] MozReview Request: bz://1134722/wcosta /r/5663 - Bug 1134722: Add aries building config files. Pull down this commit: hg pull review -r fe2de7cdc57cf4bf28dd27e991da8bfa381e71e5

Comment on attachment 8579632 [details] MozReview Request: bz://1134722/wcosta https://reviewboard.mozilla.org/r/5661/#review4665 Ship It!

Comment on attachment 8580288 [details] Support aries device in mozharness Michael already commented on the PR and I agree with him :)

Comment on attachment 8579632 [details] MozReview Request: bz://1134722/wcosta Cypress: https://hg.mozilla.org/projects/cypress/rev/fe2de7cdc57c

Comment on attachment 8580698 [details] Replace shinano by aries manifest Just a nit commented on github :)

Comment on attachment 8579627 [details] MozReview Request: bz://1134722/wcosta https://reviewboard.mozilla.org/r/5657/#review4887 Ship It!

https://github.com/mozilla-b2g/b2g-manifest/commit/65509bcdf335b8205c154b77f218f27f64b9d2dc https://github.com/mozilla-b2g/B2G/commit/fe0184b13f5c8add7084d3f174fa9c0fa48f1e71

Mozharness change landed on default: https://hg.mozilla.org/build/mozharness/rev/1b4de9a1441d

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

I notice that attachment 8579627 [details] will break the travis of b2g-manifest on v2.2 branch as [1]. And I think it could also break all branches other than master if shinano.xml is missing. Do you have any idea? Thanks! [1] https://travis-ci.org/mozilla-b2g/b2g-manifest/builds/58231915

(In reply to Kai-Zhen Li [:kli][:seinlin] from comment #17) > I notice that attachment 8579627 [details] will break the travis of > b2g-manifest on v2.2 branch as [1]. And I think it could also break all > branches other than master if shinano.xml is missing. Do you have any idea? > > Thanks! > > [1] https://travis-ci.org/mozilla-b2g/b2g-manifest/builds/58231915 This is an interesting problem. Having dived into the b2g bumper configs (https://github.com/mozilla/build-mozharness/tree/master/configs/b2g_bumper/), I see that b2g bumper is running against b2g-inbound (master.py), plus the various b2g release branches (https://hg.mozilla.org/releases/mozilla-b2g*_v*), each for multiple devices, plus against cypress for aries only (aries.py). B2G Bumper scans this mozharness directory for all configs, and runs all of them. Each config specifies the b2g-manifests repo and branch to check out (e.g. https://github.com/mozilla/build-mozharness/blob/master/configs/b2g_bumper/v2.2.py#L14-L15) and this is how b2g bumper knows which branch of version of b2g-manifest to use. Now going back to the travis problem on b2g-manifest... When a change lands on any given b2g-manifest branch, in order to test it, in theory we should "look up" which b2g bumper mozharness config(s) refer to the branch we are on, and run b2g bumper tests using a sanitised version of that config. For example, if a change lands on the v2.2 branch of b2g-manifest, the travis tests for b2g-manifest should detect that the change is on the v2.2 branch, scan the mozharness configs to find https://github.com/mozilla/build-mozharness/blob/master/configs/b2g_bumper/v2.2.py#L14-L15 and thereby ascertain that the v2.2.py b2g bumper config should be used in the travis tests. At the moment, we simply run across all configs (e.g. see https://github.com/mozilla-b2g/b2g-manifest/blob/master/run_travis_tests.sh#L48). This causes problems, since we are essentially running b2g bumper tests for a different branch of b2g-manifest than we are currently on, which means we can get invalid failures. Detecting the branch name automatically in the run_travis_tests.sh script is also not enough, since when somebody forks b2g-manifest to make a change, they will potentially create a different branch name (e.g. including the bug number) which will then make it hard to know which branch it was originally forked from. The available options I see are: 1) explicitly include the branch name in a config of b2g-manifest 2) explicitly refer to the correct mozharness config(s) in each branch of b2g-manifest (e.g. instead of *.py on line https://github.com/mozilla-b2g/b2g-manifest/blob/master/run_travis_tests.sh#L48, include the config which pertains to the branch you have currently checked out - so the content of the file would vary per branch) The problem with both solutions is that when a new branch gets added to b2g-manifest, you need to make sure you update it. I don't see any obvious way to enforce this. At best, maybe we could log a warning if we detect the currently checked out git branch name of the b2g-manifest repo doesn't match the value found in the b2g bumper config manifests_revision property of the explicitly specified config file referenced in the run_travis_tests.sh script. I'll raise a separate bug for this...

Pmoore, Thanks!

Reopening since we need this on m-c.

Resetting Version and Target Milestone that accidentally got changed...