Thunderbird 52.0 build4: failed at update_verify_release

RESOLVED FIXED

Status

enhancement
P2
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: wsmwk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [releaseduty])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
+++ This bug was initially created as a clone of Bug #1349525 +++

follow up to bug 1349525 and IRC

"Balrog prevents 45 users to update to 52. This is why we have these failures. We can temporarily change the rules on the localtest channel to make these tests work."

... then "we can fix those [failures] without build5".
(Reporter)

Comment 1

2 years ago
The logs have...

  <update type="minor" displayVersion="45.8.0" appVersion="45.8.0" platformVersion="45.8.0" buildID="20170305125302" detailsURL="https://www.mozilla.org/sk/thunderbird/45.8.0/releasenotes/">
        <patch type="complete" URL="http://archive.mozilla.org/pub/thunderbird/candidates/45.8.0-candidates/build1/update/mac/sk/thunderbird-45.8.0.complete.mar" hashFunction="sha512" hashValue="3bb81d2dcda31a1a43b151be5f9ab27435e611ac6e65f0c9e1764eeec320b3a87dbcb2b3c7f305f0d56c6d6e658784ad73bef444708c3774e6cb55c7af2cbe27" size="76038416"/>
    </update>
</updates>

FAIL: expected buildID 20170321161200 does not match actual 20170305125302
FAIL: download_mars returned non-zero exit code: 1

Updated

2 years ago
Whiteboard: [releaseduty]
The rules in Balrog currently only update to 52.0 if the request has version >=52.0, otherwise 45.8.0, so no surprises at the update verify failures for 45.x. It looks like it's setup for whatever comes after 52.0 tbh.

In email :wsmwk said he would like user-initiated update requests (ie Help > Update) to find 52.0, with the implication that background checks would not. I'd suggest that should be implemented with a single rule which points to 52.0, throttled down to a rate of 0, and fallback to 45.8.0. Same care would be needed to set aliases properly for the automation.

The update verify checks use ?force=1 on the update requests, the same as user requests.
(Reporter)

Comment 3

2 years ago
from 2017-03-29
wsmwk	rail-bbl: nthomas: anything else you need from me? perchance someone will be pushing Bug 1351429 today?
jlorenzo	wsmwk: I'm gonna make the change and leave it to rail for review
jlorenzo	rail-bbl: https://aus4-admin.mozilla.org/rules/scheduled_changes . that's gonna be enacted in 90 minutes
Flags: needinfo?(rail)
I reran the failed jobs
Flags: needinfo?(rail)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
release-cdntest needed to be updated as well at [1]. I suspect the release channel[2] will need the same changes. Reopening.

Per bhearsum's suggestion on IRC, the esr 45 rule on cdntest[3] is scheduled to be deleted (in 10 hours). Same thing for localtest[4]

[1] https://aus4-admin.mozilla.org/rules/517
[2] https://aus4-admin.mozilla.org/rules/516
[3] https://aus4-admin.mozilla.org/rules/334
[4] https://aus4-admin.mozilla.org/rules/333
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 6

2 years ago
> I suspect the release channel[2] will need the same changes. Reopening.

Is this a blocker for going live on release channel?  Because my plan is to go live today as soon as we have redirects in place.

(Message in draft, just need to click send, "Please make this live on release channel with same rules as cdntest, namely allow forced updates from version 45, but NO background updates." )
Flags: needinfo?(jlorenzo)
This is a blocker. Without this change, I suspect no update will be visible on balog. This email should be enough, IMO.
Flags: needinfo?(jlorenzo)
Rule on the release channel[1] has been updated to deliver 52.0 (and 45.8.0 as fallback) to all users. This follows the same logic as what we have on {cdn,local}test. Closing bug.

[1] https://aus4-admin.mozilla.org/rules/516
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
Unfortunately the Rate on rule 516 was set to 100, so all update requests were given 52.0 instead of just the user-initiated ones. This was corrected by Aki after 4h or so, following wsmwk's ping on IRC. Firefox QA verifies throttling settings, perhaps Thunderbird could add this too.
(Reporter)

Comment 10

2 years ago
(In reply to Johan Lorenzo [:jlorenzo] from comment #8)
> Rule on the release channel[1] has been updated to deliver 52.0 (and 45.8.0
> as fallback) to all users. This follows the same logic as what we have on
> {cdn,local}test. Closing bug.
> 
> [1] https://aus4-admin.mozilla.org/rules/516

If we build a 52.0.1, do we need any changes related to the issues of this bug before we GTB?


(In reply to Nick Thomas [:nthomas] from comment #9)
> Unfortunately the Rate on rule 516 was set to 100, so all update requests
> were given 52.0 instead of just the user-initiated ones. This was corrected
> by Aki after 4h or so, following wsmwk's ping on IRC. Firefox QA verifies
> throttling settings, perhaps Thunderbird could add this too.

thanks for the suggestion. I've added it to the list
Flags: needinfo?(jlorenzo)
I believe the alias `thunderbird-esr52{,-cdntest,-localtest}` will automatically be updated to 52.0.1. So no further changes needed, IMO.
Flags: needinfo?(jlorenzo)
(Reporter)

Comment 12

2 years ago
Looks like we are seeing this again for Thunderbird 52.0.1 build1

ALL update_verify for ALL OS are failing.  Something to do with 45.8.0 again?
https://bugzilla.mozilla.org/show_bug.cgi?id=1351429  Thunderbird 52.0 build4: failed at update_verify_release ?

from https://archive.mozilla.org/pub/thunderbird/candidates/52.0.1-candidates/build1/logs/release-comm-esr52-win32_release_update_verify_6-bm72-build1-build0.txt.gz
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment hidden (mozreview-request)

Comment 14

2 years ago
mozreview-review
Comment on attachment 8857879 [details]
Bug 1351429 - Thunderbird 52.0.1: fix update_verify_release

https://reviewboard.mozilla.org/r/129906/#review132528
Attachment #8857879 - Flags: review?(rail) → review+
Comment hidden (mozreview-request)
Attachment 8857879 [details] landed at https://hg.mozilla.org/build/tools/rev/e93248b836540abbd5e59725986d1a257f9a7568. I haven't retagged because we ended up ignoring the errors in the run in comment 12. This will be picked up by the next build.
Bug 1363711 for the next iteration on this problem, lets close this one.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.