725703 - tests should figure out the app name for fennec instead of hardcoding everywhere

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P4)

Description

[Aki Sasaki (not active)]

As of bug 703080, we now have a way to figure out the appname from an apk.
It's debatable if it's useful to fail when the appname is incorrect on mozilla-{central,aurora,beta,release}, since nothing else is testing branding.

However, on Try we should definitely try to grab package-name.txt from the apk.  If that succeeds, then the package name should be in there; otherwise we can assume org.mozilla.fennec.

Comment 2

[Aki Sasaki (not active)]

Bug 703080 only fixed Android native. We need the equivalent for android-xul.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

This will be useful for Autolanding on branches since we'll want proper try of mozilla-{esr10,beta,aurora} before pushing to those branches with autoland.

Comment 4

[Justin Wood (:Callek)]

(In reply to Aki Sasaki [:aki] from comment #2)
> Bug 703080 only fixed Android native. We need the equivalent for android-xul.

Not anymore, so we should now always have |package-name.txt| available for this. That said I'm not currently working on this.

Comment 5

[Justin Wood (:Callek)]

Hey Alex, this came up today in a different context, but I want to know if you consider the:

"Merge Day Missed branding changes for mobile" a use-case we need to continue watching for in the automation.

If we don't it allows us to remove a whole bunch of hardcodes, and potential releng automation issues, but then we have nothing, other than QA, doing branding sanity checks. (And QA doesn't check all the builds we generate, e.g. Android NoIonmonkey, Android Debug)

Either way I expect releng to implement some subset of this work item, the direction we take however, will rely on your answer. ("Keep the check" will be a bit harder, believe it or not)

-- FWIW I'm not giving an ETA on this being worked on, so no rush on answer.

Comment 6

[Alex Keybl [:akeybl]]

(In reply to Justin Wood (:Callek) from comment #5)
> "Merge Day Missed branding changes for mobile" a use-case we need to
> continue watching for in the automation.

Where are these automation results currently presented? I know philor has previously filed a bug on branding mistakes on x86 Android builds (which is helpful), so perhaps these tests were what tipped him off.

Comment 7

[Phil Ringnalda (:philor)]

In the current world, if you don't update the branding as part of a merge, then every single test fails to start up, and tbpl shows a solid row of orange/red, and I either file a bug or more commonly just push the fix.

With this bug fixed, the tests would still run, and your only clue that you forgot about a branding change would be when someone, perhaps QA, noticed that the app had the wrong branding.

Comment 8

[Justin Wood (:Callek)]

For posterity after an e-mail thread with akeybl (for relman) and kbronsnan for QA they were ok with taking this in terms of the more-manual-work and loss of safety net in branding.

Comment 9

[Justin Wood (:Callek)]

Attachment: [custom] v1

This is untested so far, but I'll test before I deploy one way or another (and won't deploy on a friday either)

All branches we care about have this file (including b2g18)

Comment 10

[Justin Wood (:Callek)]

Attachment: [configs] v1

Comment 11

[Aki Sasaki (not active)]

Comment on attachment 733804 [details] [diff] [review]
[custom] v1

r=me with the promised testing.

Comment 12

[Justin Wood (:Callek)]

Attachment: [custom] v1.1

Fixes issues uncovered in testing, including reconfig busting regression from http://hg.mozilla.org/build/buildbotcustom/rev/e854634ca5bb

Comment 13

[Aki Sasaki (not active)]

Comment on attachment 735953 [details] [diff] [review]
[custom] v1.1

The interdiff makes sense.

Comment 14

[Justin Wood (:Callek)]

This is now pushed, just waiting on a reconf

Comment 15

[Rail Aliiev [:rail]]

in production