679746 - If a signed candidate build cannot be found the script should fall back to unsigned builds

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Automation, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

When we have to run functional tests for release candidate builds we don't have signed builds for Windows in nearly all the cases. Right now the download script fails because it expects signed builds. In case of no signed builds available the script has to download the unsigned ones. For now it only applies to Windows but we should implement it flexible so it will also work for other platforms.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v1

Beside the new feature of downloading unsigned builds as fallback, this patch also fixes a couple of bugs in different scripts.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v1.1

I should qrefresh first.

Comment 3

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Comment on attachment 553818 [details] [diff] [review]
Patch v1.1

r+.

I'd like to address that "Downloading build:" logging at some point. Using build.final_url is problematic because if final_url doesn't resolve it throws an exception without telling you what it was trying to download.

The solution I would have proposed would have been to have testrun_release.py log the information it initialized build with. By moving the logging into download(), I don't know if that same strategy would work. 

It's definitely the number one pain-point I've had with the script, though, esp. for the -real/-realreal type directories they occasionally do where the build name isn't intuitive.

On that subject, in:

ReleaseScraper(MozillaScraper)

...where you have the exception handler that falls back to unsigned, would it make sense to have a little bit of log output saying it had to do that?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Geo Mealer [:geo] from comment #3)
> I'd like to address that "Downloading build:" logging at some point. Using
> build.final_url is problematic because if final_url doesn't resolve it
> throws an exception without telling you what it was trying to download.
>
> The solution I would have proposed would have been to have
> testrun_release.py log the information it initialized build with. By moving
> the logging into download(), I don't know if that same strategy would work. 

I'm aware of this and it's something I will address with the refactoring which is necessary to get more types of builds included. Lets do that in another patch.

> On that subject, in:
> 
> ReleaseScraper(MozillaScraper)
> 
> ...where you have the exception handler that falls back to unsigned, would
> it make sense to have a little bit of log output saying it had to do that?

Sure. I can add this before the check-in.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v2

Updated patch with a logging line if we fallback to unsigned builds.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Landed as:
http://hg.mozilla.org/qa/mozmill-automation/rev/15b7358e714d