Closed Bug 960781 Opened 7 years ago Closed 7 years ago

Ensure software update tests can handle new final release process (Beta N -> RC N -> Beta N+1)

Categories

(Mozilla QA Graveyard :: Mozmill Automation, defect, P1)

defect

Tracking

(firefox29 fixed)

VERIFIED FIXED
Tracking Status
firefox29 --- fixed

People

(Reporter: tracy, Assigned: cosmin-malutan)

Details

(Keywords: verifyme)

Attachments

(2 obsolete files)

I think this may be invalid. But we just want to make sure Mozmill Automation will not break come time for final build testing of 27.  This was formally beta10 then an RC.  Now the two are one in the same.  

Per https://wiki.mozilla.org/User:NThomas:Process_changes. we'll be making what used to be beta10 as 27.0 final candidate available on beta channel. Then make the same exact build available on release come that time.

I think, as long as the on-demand config files are correct, that we can test both scenarios; that beta testers get updated to the 27.0 final build and also that release users get updated when release channel goes live.

Henrik, I also think that the pulse triggered functional runs should just work as well, correct?

If there is something to address here on Mozmill backend side, please do so.  Otherwise, feel free to mark invalid.  Thanks.
mozmill-automation lives on github those days: https://github.com/mozilla/mozmill-automation/. So we should get the remaining bugs here moved over and push the component into the graveyard.

All the above cases Mozmill CI is able to cover. It doesn't matter how many builds we get or from which branch. The right branch selection on our side gets taken out from the application.ini file. For updates you are responsible for defining the right builds and channel to use. So all is fine here.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
This does not work.  

Use http://mozilla.github.io/mciconf/app/ to generate:

[testrun]
script=update
report=http://mozauto.iriscouch.com/mozmill-release/
target-build-id=20140203225656
channel=betatest
[windows xp 32bit]
platform=win32
27.0#1=en-US

We have no way to tell Mozmill the difference in build location between 27.0RC and 27.0.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
We need mozmill to edit the RC build to behave like a beta channel build that has been updated from a previous beta build.  Anthony can elaborate.
Basically what we need to support is RCs -> Betas on the beta channel. Here is an example of the test we need to cover:
https://moztrap.mozilla.org/manage/case/11480/

Whereas the current Mozmill test does the following:
* Downloads the source build
* Changes the update channel
* Checks for updates
* Restarts
* Verifies the correct target build ID

We want the Mozmill test to be able to:
* Download the RC build
* Change the update channel
* Change update-settings.ini
* Check for updates
* Restart
* Verifies the correct target build ID

If this can be done in a way that allows us to upload a single config file for Beta->Beta and RC->Beta updates that would be great. However this is not an MVP requirement. Worst case scenario we would need to update a config file to test all the Beta->Beta permutations and a second to test the RC->Beta permutations.

Note that this is something we'll need to test with every Beta going forward. Until this works with Mozmill we'll be doing this completely by hand which I expect to take considerable time and effort.

Please let me know if you need further clarification.
So what about this update-channel.ini file? Is that something new? If yes, please tell us what it is doing. I haven't heard from it yet. 

Also when we have coverage of multiple update steps we might not need this file because we already can test from a beta build as source. So I don't think that we should start to do any other modifications.
Flags: needinfo?(anthony.s.hughes)
Nick, can you answer Henrik's questions in comment 5?
Flags: needinfo?(anthony.s.hughes)
Flags: needinfo?(nthomas)
update-settings.ini was added when the maintenance service made it possible for users with limited rights to install updates (ie part of silent updates by taking away the UAC prompt on Vista & higher). The mar files are tagged with a channel-id, which must be in the list in update-settings.ini for the updater to accept to the file. We also sign the mar with a cert known to the updater, to ensure no tampering.

The update-settings.ini file lives at the base of the install directory, and looks like this for beta:
; If you modify this file updates may fail.
; Do not modify this file.

[Settings]
ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-beta,firefox-mozilla-release
-----

If we take the RC build we have this line instead
  ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-release
but the mar file for the new beta will have the firefox-mozilla-beta id applied. Hence the request to have mozmill support for modifying update-settings.ini.

If you would prefer not to support that, we'll need this instead
* install beta from last version
* update on channel A (eg brbtest) to known buildID (the release build)
* update on channel B (eg betatest) to another known buildID (the new beta)
Those two channels cannot be the same, because we also want to test old beta -> new beta on betatest.

I leave any discussions about what the best test is to you guys.
Flags: needinfo?(nthomas)
Henrik, do you have the info you need to get moving on this? We want a solution in place by Firefox 28.0rc and want something in place to test before by 28.0b7 at the lastest if possible.
Flags: needinfo?(hskupin)
We also have Metro and FxAccounts in-front of us. So we will have to let Marc speak up here about the prioritization. But as what we agreed on and how the goals are listed its this order:

* Metro
* FxAccount
* Update tests

It doesn't mean that we cannot work in parallel but right now I can't promise when we will have a solution for the update tests.

Also I can't say if I have enough information right now. Most likely. But i will report back once we were able to get the update tests transformed to a state machine.
Flags: needinfo?(hskupin) → needinfo?(mschifer)
As discussed in our team meeting the priority is as follows:

1. Metro
2. Update tests

As an MVP for these new update tests I propose the following.

The first test will be Beta -> RC updates. These will be performed the day we push RC builds to the Beta channel (where normally this would be Beta 10). I don't think anything has to change here since nothing special is taking place. We'd just supply the build ID of the RC in the config file and the test should pass as per normal.

The second test, RC -> Beta, will occur the day we want to push out the Beta for the next major Firefox version. This test will be a bit different than what our current update tests are capable of. Here are the steps:

1. Download and install Firefox RC
2. Edit the update channel in channel-prefs.js as required (Mozmill tests already do this)
3. Edit the ACCEPTED_MAR_CHANNEL_IDS line in update-settings.ini to ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-beta,firefox-mozilla-release (Mozmill tests do NOT currently do this)
4. Check for updates
5. Restart Firefox and check the build ID against the config file (Mozmill tests already do this)
* We'd also need this test performed with a fallback in the case of RC -> Beta 1 since we're providing a partial update in this instance alone.

The third test would be Beta -> RC -> Beta but I don't think there's a need for Mozmill to cover this. We did test this Beta->RC->Beta path the first time around to prove the mechanism RelEng had in place  and since this was the first time we were doing this. As we now have confidence in the system I don't think it's necessary for Mozmill to ensure Beta->RC->Beta. 

Ultimately I do not think this should require much change. Just adding an additional test which takes the existing update test and adds a step 3. The test itself will only be run when we are doing either a Beta->RC update or a RC->Beta update. If it makes it simpler I would be fine with needing to specify this in a separate on-demand config file.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #10)
> * We'd also need this test performed with a fallback in the case of RC ->
> Beta 1 since we're providing a partial update in this instance alone.

I suggest general support for fallback (already in place anyway?) In an ideal world we want to offer partial updates from the last two builds we've put on the beta channel, were the sequence would look like
   N.0b8  -->  N.0b9  -->   N.0 rc  -->  N+1.0b1  -->  N+1.0b2
ie would like to test fall back from rc to b2

And if we can support multiple rc's
   N.0b8  -->  N.0b9  -->   N.0 rc1  -->   N.0 rc2  -->  N+1.0b1  -->  N+1.0b2
all the better. We'd need to modify update-settings.ini whenever we start with an rc build.
For handling multiple update steps we would first need bug 604364 to be fixed. Adding the dependency.

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #10)
> The first test will be Beta -> RC updates. These will be performed the day
> we push RC builds to the Beta channel (where normally this would be Beta
> 10). I don't think anything has to change here since nothing special is
> taking place. We'd just supply the build ID of the RC in the config file and
> the test should pass as per normal.

That's correct. And there is nothing else to check? What about the channel? It stays the same?

> The second test, RC -> Beta, will occur the day we want to push out the Beta
> for the next major Firefox version. This test will be a bit different than
> what our current update tests are capable of. Here are the steps:
> 
> 1. Download and install Firefox RC
> 2. Edit the update channel in channel-prefs.js as required (Mozmill tests
> already do this)
> 3. Edit the ACCEPTED_MAR_CHANNEL_IDS line in update-settings.ini to
> ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-beta,firefox-mozilla-release
> (Mozmill tests do NOT currently do this)
> 4. Check for updates
> 5. Restart Firefox and check the build ID against the config file (Mozmill
> tests already do this)
> * We'd also need this test performed with a fallback in the case of RC ->
> Beta 1 since we're providing a partial update in this instance alone.

As we talked about this, it's not something we can do in the short term. It adds way more complexity to the tests. I would propose we push this out.

> The third test would be Beta -> RC -> Beta but I don't think there's a need
> for Mozmill to cover this. We did test this Beta->RC->Beta path the first
> time around to prove the mechanism RelEng had in place  and since this was
> the first time we were doing this. As we now have confidence in the system I
> don't think it's necessary for Mozmill to ensure Beta->RC->Beta. 

Actually this would be way easier for us to test, given that we wouldn't have to do all this kind of extra steps to prepare the build. I really would like to follow this path for the first implementation.

(In reply to Nick Thomas [:nthomas] from comment #11)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #10)
> > * We'd also need this test performed with a fallback in the case of RC ->
> > Beta 1 since we're providing a partial update in this instance alone.
> 
> I suggest general support for fallback (already in place anyway?) In an
> ideal world we want to offer partial updates from the last two builds we've
> put on the beta channel, were the sequence would look like
>    N.0b8  -->  N.0b9  -->   N.0 rc  -->  N+1.0b1  -->  N+1.0b2
> ie would like to test fall back from rc to b2
> 
> And if we can support multiple rc's
>    N.0b8  -->  N.0b9  -->   N.0 rc1  -->   N.0 rc2  -->  N+1.0b1  --> 
> N+1.0b2
> all the better. We'd need to modify update-settings.ini whenever we start
> with an rc build.

General fallbacks are hard to do, especially over multiple steps involved. So the matrix would grow dramatically. I kinda would like to avoid that. Here an example:

1) N b9 -> partial -> N rc -> partial -> N+1 b1
2) N b9 -> fallback -> N rc -> partial -> N+1 b1
3) N b9 -> partial -> N rc -> fallback -> N+1 b1
4) N b9 -> fallback -> N rc -> fallback -> N+1 b1

What I would propose here is that we follow path 1) and 4) with either partial or fallback, but not with a mix of both of them. Does that all sound fine?
Status: REOPENED → NEW
Depends on: 604364
Flags: needinfo?(mschifer)
Hardware: x86 → All
Summary: Ensure Mozmill can handle new final release process. → Ensure software update tests can handle new final release process (Beta N -> RC N -> Beta N+1)
Nick, I don't want what we want to support in the future to distract us from what we need to support today. Bottom line, if we want to be sure we aren't breaking updates to users today we need to add support to automate testing the following:

1. Beta 9 -> RC when we ship a new Release
2. RC -> Beta N when we ship a new Beta

Anything else is a nice to have in my opinion and should be broken out. We really need to get this minimum set of new tests covered ASAP as you're getting the absolute minimum coverage today. QA is forced into a position of creating significant gaps in our platform and locale coverage so that we can meet the strict deadlines imposed upon us. This situation only gets worse with each new release as we have more and more builds to test.

Henrik, I fail to see why the above two tests are so complex. What's the absolute minimum you can get done before Firefox 28 releases?
At the risk of being unhelpful again, I'm going to offer a design suggestion without knowing the code:

* Add a config variable which controls what ACCEPTED_MAR_CHANNEL_IDS should be set to
* If it's set, modify update-settings.ini by putting the config value in

Anthony & co would only set the variable when testing updates from an RC build to a beta build. That covers all recent situations, and proposed extensions. NB: This is for A->B, not A->B->C updates.

BTW, I really don't want to invent process for rc1 -> rc2 on beta the first time it happens in production; nor do I believe it is different from testing point-to-point updates for rc -> beta, so that we can support with almost zero cost.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Priority: -- → P5
Priority: P5 → P1
(In reply to Nick Thomas [:nthomas] from comment #7)
> If we take the RC build we have this line instead
>   ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-release
> but the mar file for the new beta will have the firefox-mozilla-beta id
> applied. Hence the request to have mozmill support for modifying
> update-settings.ini.
I'm still not sure what we would have to do here, I took builds from candidates directory and they have both firefox-mozilla-beta and firefox-mozilla-release channel-ids in update-settings.ini file.
https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/28.0b9-candidates/

Is there a build on which I could check the steps manually, before we can start on this?
I'm not sure that this is what is needed, but if we want to change the update-settings.ini before we ran the tests we would have to make a small update in mozmill-ci to add the parameter for the job and to set it in mozmill-automation.

This is patch is only for feedback, I will come up with the one for mozmill-automation.
Attachment #8389862 - Flags: feedback?(hskupin)
Comment on attachment 8389862 [details] [diff] [review]
0001-Add-accepted-mar-channel-ids-parameter-to-ondemand_u.patch

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

This is mozmill-ci code and has nothing to do with this bug. As I have said yesterday, I wanted to have a discussion first before you are getting started. Sadly that didn't happen as I can see now. :/
Attachment #8389862 - Flags: feedback?(hskupin)
Attachment #8389862 - Attachment is obsolete: true
Comment on attachment 8389863 [details] [diff] [review]
0001-Add-accepted-mar-channel-ids-parameter-to-update-tes.patch

This is mozmill-automation code and also doesn't apply to this bug.
Attachment #8389863 - Attachment is obsolete: true
As we discussed in our ask-an-expert meeting we would like to set the ACCEPTED_MAR_CHANNEL_IDS in update-settings.ini based on the --channel parameter, for that I would need to know what are the valid entries for ACCEPTED_MAR_CHANNEL_IDS.

Nick do you know from where I could get the valid entries for the ACCEPTED_MAR_CHANNEL_IDS?
Flags: needinfo?(nthomas)
(In reply to Cosmin Malutan from comment #20)
> Nick do you know from where I could get the valid entries for the
> ACCEPTED_MAR_CHANNEL_IDS?

Just to add because that's missing in the question, we have to know that for all kinds of builds not only release and beta, but also aurora, nightly, and the upcoming esr nightly for 31.0.
There isn't multiple values we need to deal with here. There is only one case where ACCEPTED_MAR_CHANNEL_IDS needs to change, and that's when we are pushing a new Beta to RC users who expect a beta (ie. users who went from Beta -> RC). For this case the value of ACCEPTED_MAR_CHANNEL_IDS needs to change to firefox-mozilla-beta,firefox-mozilla-release for all channels we want to test.

In all other cases (ie. Beta->Beta and Release->Release) we will leave ACCEPTED_MAR_CHANNEL_IDS unchanged.
Anthony, for automation we need those details. We can't special-case it that way as you do when running that manually. We want to make it work for any case, so not only for RC-Beta.
(In reply to Henrik Skupin (:whimboo) from comment #23)
> Anthony, for automation we need those details. We can't special-case it that
> way as you do when running that manually. We want to make it work for any
> case, so not only for RC-Beta.

Agreed, but I think Beta->Beta, Release->Release, and Release->Beta are the only cases we'll need to deal with; the latter being the only "special case". Regardless, I don't think parsing out the channel parameter is going to get you what you need. I'll leave it to Nick to correct me if I'm wrong.
So as explanation for you what we wanna do in case of RC -> Beta

1. Set the update channel to beta via --channel=beta
2. Check allowed update channels, and if the channel as specified above is not contained, we will add it. We might have to strip of the 'test' in case of betatest
3. Execute the update
4. After the upgrade check allowed channels that it is still the same and has not been changed.
I agree with Anthony's comments, we should only modify updates-settings.ini in the Release -> Beta case. Bonus points for only doing it to release builds (beta builds don't need it).

Whimboo & I talked it out on IRC, and got to

whimboo:	 so we should indeed have an optional command line option
         --override-update-settings
         that way it is under the control of the user
Flags: needinfo?(nthomas)
I opened pr 133 for mozmill-automation, I will prepare one for mozmill-ci now.
https://github.com/mozilla/mozmill-automation/pull/133
I opened pr 429 for adding the parameter for mozmill-ci
https://github.com/mozilla/mozmill-ci/pull/429
(In reply to Cosmin Malutan from comment #27)
> https://github.com/mozilla/mozmill-automation/pull/133

This pull has been landed now. I will prepare a patch so we can get mozmill-automation 2.0.6.1 released by tomorrow. Once done and the new environments are active, we can also get the remaining mozmill-ci patch out.
Nick, is there a way to get this tested? Could we have a fake channel to use? I don't want to wait for that until the next RC -> Beta test.
Flags: needinfo?(nthomas)
Also the remaining Mozmill-CI patch has been landed, and is available on staging for testing. 
https://github.com/mozilla/mozmill-ci/commit/1657a35475e05b63f0a19771e5b0fd2623cbc9eb

So as asked in my last comment we are waiting for details how to verify that it works. So Nick and Anthony, what can we do here?
Assignee: hskupin → cosmin.malutan
Flags: needinfo?(anthony.s.hughes)
Keywords: verifyme
Status: ASSIGNED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Would retesting the 27.0 case be OK ? I think we still have snippets for betas -> 27.0 rc, and shipped 27.0 -> 28.0b1 around, which could be used to repopulate the test channels. I'd need to review them first to make sure we weren't causing problems. Presumably you would need those pushed at separate times, to avoid errors when mozmill does a final check for updates and isn't expecting to find anything.
Flags: needinfo?(nthomas)
Whatever you would have for us would be fine. It doesn't matter which version. Just tell us the source and target build, and the channel name. Then we can get this tested. Thanks.
I can assist with testing as needed but I'll leave it up to Nick to determine what best to stage.
Flags: needinfo?(anthony.s.hughes)
Nick, will it be possible for you to have something for us by tomorrow? We really would like to push our code to mozmill-ci production. But I'm hesitated doing so for untested features. Thanks.
Flags: needinfo?(nthomas)
I've repushed the snippets for 27.0 release build -> 28.0b1. It's all locales, all platforms, partial + complete updates, releasetest channel. This will persist until we do 28.0.1 or 29.0.
Flags: needinfo?(nthomas)
I downloaded the Firefox 27.0 I updated the update.channel to releasetest and updated the accepted mar channels in update-settings.ini manually and tried to update the firefox, but I get "Update failed".
I tried manually after I've got the same message and log in a testrun. 
The log for this is:
>13:48:32 *** AUS:SVC Checker: checkForUpdates, force: true
>13:48:32 *** AUS:SVC getLocale - getting locale from file: resource://gre/update.locale, locale: en-US
>13:48:32 *** AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/27.0/20140127194636/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/releasetest/Darwin%2011.4.2/default/default/update.xml?force=1
>13:48:32 *** AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/27.0/20140127194636/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/releasetest/Darwin%2011.4.2/default/default/update.xml?force=1
>13:48:33 *** AUS:SVC Checker:onLoad - request completed downloading document
>13:48:33 *** AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/27.0/20140127194636/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/releasetest/Darwin%2011.4.2/default/default/update.xml?force=1
>13:48:33 *** AUS:SVC Checker:onLoad - number of updates available: 1
>13:48:33 *** AUS:SVC gCanApplyUpdates - testing write access /Users/danielapetrovici/workspace/ondemand_update/data/binary/Firefox.app/Contents/MacOS/update.test
>13:48:33 *** AUS:SVC gCanApplyUpdates - able to apply updates
>13:48:33 *** AUS:SVC Creating Downloader
>13:48:33 *** AUS:SVC UpdateService:_downloadUpdate
>13:48:33 *** AUS:SVC readStringFromFile - file doesn't exist: /Users/danielapetrovici/workspace/ondemand_update/data/binary/Firefox.app/Contents/MacOS/updates/0/update.status
>13:48:33 *** AUS:SVC readStatusFile - status: null, path: /Users/danielapetrovici/workspace/ondemand_update/data/binary/Firefox.app/Contents/MacOS/updates/0/update.status
>13:48:33 *** AUS:SVC Downloader:downloadUpdate - downloading from http://download.mozilla.org/?product=firefox-28.0b1-partial-27.0&os=osx&lang=en-US&force=1 to /Users/danielapetrovici/workspace/ondemand_update/data/binary/Firefox.app/Contents/MacOS/updates/0/update.mar
>13:48:34 *** AUS:SVC Downloader:onStartRequest - original URI spec: http://download.mozilla.org/?product=firefox-28.0b1-partial-27.0&os=osx&lang=en-US&force=1, final URI spec: http://download.cdn.mozilla.net/pub/firefox/releases/28.0b1/update/mac/en-US/firefox-27.0-28.0b1.partial.mar
>13:48:34 *** AUS:SVC Downloader:onProgress - progress: 53136/19154434
>13:48:34 *** AUS:SVC Downloader:onProgress - maxProgress: 19154434 is not equal to expectd patch size: 19154941
>13:48:34 *** AUS:SVC Downloader: cancel
>13:48:34 *** AUS:SVC Downloader:onProgress - progress: 0/19154434
>13:48:34 *** AUS:SVC Downloader:onProgress - maxProgress: 19154434 is not equal to expectd patch size: 19154941
>13:48:34 *** AUS:SVC Downloader: cancel
>13:48:34 *** AUS:SVC Downloader:onStopRequest - original URI spec: http://download.mozilla.org/?product=firefox-28.0b1-partial-27.0&os=osx&lang=en-US&force=1, final URI spec: http://download.cdn.mozilla.net/pub/firefox/releases/28.0b1/update/mac/en-US/firefox-27.0-28.0b1.partial.mar, status: 2147549183
>13:48:34 *** AUS:SVC Downloader:onStopRequest - status: 2147549183, current fail: 0, max fail: 10, retryTimeout: 2000
>13:48:34 *** AUS:SVC Downloader:onStopRequest - non-verification failure
>13:48:34 *** AUS:SVC getStatusTextFromCode - transfer error: Failed (unknown reason), default code: 2152398849
>13:48:34 *** AUS:SVC Downloader:onStopRequest - setting state to: download-failed
>13:48:34 *** AUS:SVC Downloader:onStopRequest - verification of patch failed, downloading complete update patch
>13:48:34 *** AUS:SVC UpdateService:_downloadUpdate
>13:48:34 *** AUS:SVC readStringFromFile - file doesn't exist: /Users/danielapetrovici/workspace/ondemand_update/data/binary/Firefox.app/Contents/MacOS/updates/0/update.status
>13:48:34 *** AUS:SVC readStatusFile - status: null, path: /Users/danielapetrovici/workspace/ondemand_update/data/binary/Firefox.app/Contents/MacOS/updates/0/update.status
>13:48:34 *** AUS:SVC Downloader:_selectPatch - found existing patch with state: null
>13:48:34 *** AUS:SVC Downloader:downloadUpdate - downloading from http://download.mozilla.org/?product=firefox-28.0b1-complete&os=osx&lang=en-US&force=1 to /Users/danielapetrovici/workspace/ondemand_update/data/binary/Firefox.app/Contents/MacOS/updates/0/update.mar
>13:48:34 *** AUS:SVC Downloader:onStartRequest - original URI spec: http://download.mozilla.org/?product=firefox-28.0b1-complete&os=osx&lang=en-US&force=1, final URI spec: http://download.cdn.mozilla.net/pub/firefox/releases/28.0b1/update/mac/en-US/firefox-28.0b1.complete.mar
>13:48:34 *** AUS:SVC Downloader:onProgress - progress: 60376/47768468
>13:48:34 *** AUS:SVC Downloader:onProgress - maxProgress: 47768468 is not equal to expectd patch size: 47769356
>13:48:34 *** AUS:SVC Downloader: cancel
>13:48:34 *** AUS:SVC Downloader:onProgress - progress: 0/47768468
>13:48:34 *** AUS:SVC Downloader:onProgress - maxProgress: 47768468 is not equal to expectd patch size: 47769356
>13:48:34 *** AUS:SVC Downloader: cancel
>13:48:34 *** AUS:SVC Downloader:onStopRequest - original URI spec: http://download.mozilla.org/?product=firefox-28.0b1-complete&os=osx&lang=en-US&force=1, final URI spec: http://download.cdn.mozilla.net/pub/firefox/releases/28.0b1/update/mac/en-US/firefox-28.0b1.complete.mar, status: 2147549183
>13:48:34 *** AUS:SVC Downloader:onStopRequest - status: 2147549183, current fail: 0, max fail: 10, retryTimeout: 2000
>13:48:34 *** AUS:SVC Downloader:onStopRequest - non-verification failure
>13:48:34 *** AUS:SVC getStatusTextFromCode - transfer error: Failed (unknown reason), default code: 2152398849
>13:48:34 *** AUS:SVC Downloader:onStopRequest - setting state to: download-failed
>13:48:34 *** AUS:SVC Downloader:onStopRequest - all update patch downloads failed
The expected patch file size seems to be wrongly calculated:

maxProgress: 19154434 is not equal to expectd patch size: 19154941

Nick, something broken in the snippet generation process?
We did two builds for 28.0b1, and I pushed build1 by mistake. Should be fixed now, sorry!

[note to me: pushed Firefox-28.0b1-build2-for27.0-test]
Product: Mozilla QA → Mozilla QA Graveyard
No longer depends on: 604364
You need to log in before you can comment on or make changes to this bug.