1255078 - Android Beta tests broken: Found installer url http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-beta-android-api-15-debug/1457532253/bouncer.apk.

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Nick Alexander :nalexander [he/him]]

This isn't right:

Found installer url http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-beta-android-api-15-debug/1457532253/bouncer.apk.

that shouldn't be picking up the new bouncer APK, it should be picking up the fennec-* APK, like always.

Comment 1

[Nick Alexander :nalexander [he/him]]

This is basically Bug 919627.

Comment 2

[Nick Alexander :nalexander [he/him]]

catlee: can you direct me to a person who can fix the URL-determining logic in beta?  This is different between {m-c, m-a}, and m-b (and release?).

Comment 3

[Chris AtLee [:catlee]]

Are the artifacts that are uploaded different between m-a and m-b?

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Chris AtLee [:catlee] from comment #3)
> Are the artifacts that are uploaded different between m-a and m-b?

I believe the artifacts are the same between m-a and m-b.  Both should be uploading an additional bouncer.apk.  I've seen bad handling of APKs before -- maybe we take alphabetically first, or whatever the filesystem lists first.

Comment 5

[Chris AtLee [:catlee]]

I'm pretty sure this is due to https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory.py#197

m-b, m-r and esr are still using this code to do android builds, whereas m-c, m-a are using mozharness scripts.

Can we ignore bouncer.apk for the purposes of figuring out the package URL?

Comment 6

[Nick Alexander :nalexander [he/him]]

(In reply to Chris AtLee [:catlee] from comment #5)
> I'm pretty sure this is due to
> https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory.
> py#197
> 
> m-b, m-r and esr are still using this code to do android builds, whereas
> m-c, m-a are using mozharness scripts.
> 
> Can we ignore bouncer.apk for the purposes of figuring out the package URL?

Are you asking me?  If so, yes -- new APKs shouldn't change anything in automation.  I can't do this work, though, since I can't schedule buildbot reconfigures.  Can you assign this to a releng person?

Comment 7

[Chris AtLee [:catlee]]

Yeah, I'm asking if the location of bouncer.apk is important to know for tests. It sounds like it's not.

Comment 8

[Alin Selagea [:aselagea]]

Attachment: bug_1255078.patch

Comment 9

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8729019 [details] [diff] [review]
bug_1255078.patch

If this is all this takes, can we try to be a little more future-proof?  Why not actually try to find APKs that look like Fennec?  For example, things that start with {fennec,firefox} and look like they have version numbers in them.  This is going to break when we upload some other APK (for example, a robocop-debug.apk, which I tried before).

Comment 10

[Chris AtLee [:catlee]]

Because we hope this code is going away in the next few months.

Comment 11

[Alin Selagea [:aselagea]]

@Nick: I think "robocop-debug.apk" would be handled fine. According to https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory.py#215, it should assign it to robocopApkUrl. 

That being said, can I go on and land the patch? Or we should try to find some workaround for this?

Thanks.

Comment 12

[Nick Alexander :nalexander [he/him]]

(In reply to Alin Selagea [:aselagea][:buildduty] from comment #11)
> @Nick: I think "robocop-debug.apk" would be handled fine. According to
> https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory.
> py#215, it should assign it to robocopApkUrl. 
> 
> That being said, can I go on and land the patch? Or we should try to find
> some workaround for this?

Thumbs up to land for me.  If this cruft is going away (in favour of whatever we do on trunk), roll on.

Comment 13

[Release Engineering SlaveAPI Service]

In production: https://hg.mozilla.org/build/buildbotcustom/rev/b4c6ed50c14c