939719 - stop packaging tests.jar up during a build

Status: RESOLVED FIXED

(Testing :: Mochitest, defect, P2)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

tests.jar was created many years ago when we were solving the problem of running tests on a device. In this case Windows Mobile so we could have the sources locally (loading .xul files over the internet was not possible).  This has stuck around and for the last couple years and hasn't been needed.

In reading about the OOM issues, it appears we have a 8MB tests.jar file which we unzip as part of our test run.  That seems a bit overkill.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: remove tests.jar (1.0)

as seen on try server:
https://tbpl.mozilla.org/?tree=Try&rev=098b5d758970

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Comment on attachment 8333759 [details] [diff] [review]
remove tests.jar (1.0)

Review of attachment 8333759 [details] [diff] [review]:
-----------------------------------------------------------------

::: docshell/test/chrome/test_bug456980.xul
@@ +20,4 @@
>  
>    <!-- test code goes here -->
>    <script type="application/javascript"><![CDATA[
> +    SimpleTest.expectAssertions(0);

Remove it instead?

::: docshell/test/chrome/test_bug608669.xul
@@ +39,4 @@
>  }
>  
>  
> +SimpleTest.expectAssertions(0);

Ditto

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: remove tests.jar (1.1)

removed expected assertions of 0 as per Ms2ger comment.

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f56094c77076

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f56094c77076

Comment 6

[Chris Cooper [:coop] (he/him)]

I'd like to request uplift of this patch to mozilla-beta, mozilla-release, and mozilla-esr24. 

Without the patch, I cannot deploy Vlad's winrm.exe tool from bug 727551 because builds fail when packaging these unused tests. 

The new winrm.exe tool can speed up directory/file removal on Windows by up to 50%. I would rather not wait out the lifecycle of mozilla-esr24 before realizing that speedup.

mozilla-release (tracking-firefox26) is only truly necessary if we expect another dot release before the next cycle, but dep builds will fail until then without the patch if winrm.exe is deployed in the interim.

Comment 7

[Chris Cooper [:coop] (he/him)]

(In reply to Chris Cooper [:coop] from comment #6)
> I'd like to request uplift of this patch to mozilla-beta, mozilla-release,
> and mozilla-esr24. 

I should also note that I've successfully created builds from patched versions of all these trees in a releng staging environment that was using the new winrm.exe.

The patch seems pretty safe to uplift based on comment #0.

Comment 8

[bhavana bajaj [:bajaj]]

(In reply to Chris Cooper [:coop] from comment #7)
> (In reply to Chris Cooper [:coop] from comment #6)
> > I'd like to request uplift of this patch to mozilla-beta, mozilla-release,
> > and mozilla-esr24. 
> 
> I should also note that I've successfully created builds from patched
> versions of all these trees in a releng staging environment that was using
> the new winrm.exe.
> 
> The patch seems pretty safe to uplift based on comment #0.

Looks like you have the testing covered and you deem it to be low risk.Can you request uplift ? I don't think its necessary to track given there is no direct end user impact.

Also our final beta for Fx27 goes to build on thursday so may be land before that. I don't expect a dot release on Fx26, so not sure if this is still needed on mozilla-release

Comment 9

[Chris Cooper [:coop] (he/him)]

(In reply to bhavana bajaj [:bajaj] from comment #8) 
> Looks like you have the testing covered and you deem it to be low risk.Can
> you request uplift ? I don't think its necessary to track given there is no
> direct end user impact.

How does one request uplift these days? I thought those flags put it on the relevant radar.
 
> Also our final beta for Fx27 goes to build on thursday so may be land before
> that. I don't expect a dot release on Fx26, so not sure if this is still
> needed on mozilla-release

Yes, it means waiting for the beta->release merge to happen, but I'd rather wait a week than multiple months for esr24.

Comment 10

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8333906 [details] [diff] [review]
remove tests.jar (1.1)

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: patch removes an unused test collection. The build config for that test collection is preventing us from deploying winrm change from bug 727551. This patch will significantly speedup file removal on Windows, and hence speedup the turnaround time of Windows builds.
User impact if declined: removing files on Windows remains slow until esr24 is EOLed
Fix Landed on Version: already in m-c and aurora; patch tested and builds created on user repo versions of beta, release, and esr24 in releng staging env. Patch required minimal reordering on esr24 due to other interim cleanup in the affected file.
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 11

[bhavana bajaj [:bajaj]]

(In reply to Chris Cooper [:coop] from comment #9)
> (In reply to bhavana bajaj [:bajaj] from comment #8) 
> > Looks like you have the testing covered and you deem it to be low risk.Can
> > you request uplift ? I don't think its necessary to track given there is no
> > direct end user impact.
> 
> How does one request uplift these days? I thought those flags put it on the
> relevant radar.

directly using the approval flags :) typically tend to track recent regressions or release blocking or significant user facing issues.
>  
> > Also our final beta for Fx27 goes to build on thursday so may be land before
> > that. I don't expect a dot release on Fx26, so not sure if this is still
> > needed on mozilla-release
> 
> Yes, it means waiting for the beta->release merge to happen, but I'd rather
> wait a week than multiple months for esr24.

Comment 12

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8333906 [details] [diff] [review]
remove tests.jar (1.1)

Review of attachment 8333906 [details] [diff] [review]:
-----------------------------------------------------------------

https://hg.mozilla.org/releases/mozilla-beta/rev/50293ac6deb8
https://hg.mozilla.org/releases/mozilla-release/rev/f17cd4055b55
https://hg.mozilla.org/releases/mozilla-esr24/rev/ad044450f729

Comment 13

[Phil Ringnalda (:philor)]

Q: Why can't we have nice things?
A: Because mochitest-chrome, browser-chrome, and mochitest-a11y on esr24 depend on things not being nice.

Backed out in https://hg.mozilla.org/releases/mozilla-esr24/rev/bc6aab7870b8

Comment 14

[Chris Cooper [:coop] (he/him)]

(In reply to Phil Ringnalda (:philor) from comment #13)
> Q: Why can't we have nice things?
> A: Because mochitest-chrome, browser-chrome, and mochitest-a11y on esr24
> depend on things not being nice.
> 
> Backed out in https://hg.mozilla.org/releases/mozilla-esr24/rev/bc6aab7870b8

I missed a part of the patch actually, or at least I hope that's what's happening. We still need to register the chrome directory, but I ripped that part out completely. 

Trying again in staging to verify.

Comment 15

[Chris Cooper [:coop] (he/him)]

Re-landed after successful test runs in staging:

https://tbpl.mozilla.org/?tree=Mozilla-Esr24&rev=303ddea4ccce

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/f9f469d5d1e1