The default bug view has changed. See this FAQ.

create balrog rules to properly support OS blocking and watershed updates on release (and equivalent test) channels

RESOLVED FIXED

Status

Release Engineering
Balrog: Backend
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: bhearsum, Assigned: bhearsum)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

3 years ago
Just like bug 1049550, but for the release channel.
(Assignee)

Comment 1

3 years ago
I created the OS blocking rule for release* today to fix a bunch of snippet comparison errors. Haven't done anything with watersheds.
Per http://people.mozilla.org/~nthomas/update-watch/release/older-releases.html
* everything from 10.0 and up gets the latest (which was 29.0.1 when the page was generated)
* 4.0 through to 9.0.1 get 12.0   (watch out for faked externsionVersion)

Details for older stuff there too, but we decided to not worry about older than 4 initially (bug 1075192).
(Assignee)

Updated

3 years ago
Assignee: nobody → bhearsum
(Assignee)

Comment 3

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #2)
> Per
> http://people.mozilla.org/~nthomas/update-watch/release/older-releases.html
> * everything from 10.0 and up gets the latest (which was 29.0.1 when the
> page was generated)
> * 4.0 through to 9.0.1 get 12.0   (watch out for faked externsionVersion)
> 
> Details for older stuff there too, but we decided to not worry about older
> than 4 initially (bug 1075192).

Thanks Nick. So this means that we just need the one watershed update with a rule like:
product: Firefox,
version: <10.0,
channel: release*,
mapping: Firefox-12.0-build1
(Assignee)

Comment 4

3 years ago
Created attachment 8503398 [details]
Firefox 12.0 build1 blob

This is my friday afternoon attempt at a 12.0 release blob. I'm not sure how you generated the 11.0b5 one, but I did this by hacking up generate-json.py and pointing it at the 12.0 releases directory.

(In reply to Nick Thomas [:nthomas] from comment #2)
> * 4.0 through to 9.0.1 get 12.0   (watch out for faked externsionVersion)

I can't figure out what you mean by this. Looking at update URLs like https://aus3.mozilla.org/update/3/Firefox/7.0/20110922153450/WINNT_x86-msvc/en-US/release/default/default/update.xml, I don't see extensionVersion...and all of the versions look unfaked.
(Assignee)

Comment 5

3 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #4)
> (In reply to Nick Thomas [:nthomas] from comment #2)
> > * 4.0 through to 9.0.1 get 12.0   (watch out for faked externsionVersion)
> 
> I can't figure out what you mean by this. Looking at update URLs like
> https://aus3.mozilla.org/update/3/Firefox/7.0/20110922153450/WINNT_x86-msvc/
> en-US/release/default/default/update.xml, I don't see extensionVersion...and
> all of the versions look unfaked.

Looks like this is actually only applicable to 3.6* and earlier. https://aus3.mozilla.org/update/1/Firefox/3.6.26/20120128224517/WINNT_x86-msvc/en-US/release/update.xml has a faked extensionVersion.
(Assignee)

Comment 6

3 years ago
I added the Firefox-12.0-build1 blob and now all tests for Firefox are passing except the Darwin 9 and GTK 2.11 ones. They're failing because those versions were supported at the time. If we want to be 100% correct, we should change the watershed rules to point them at 12.0. However, I think we implicitly (or explicitly and I forgot about it) decided not to worry about those, since they can't come close to being up to date anyways. Eg, requests like this one get no update at all (instead of the last supported release): https://aus4.mozilla.org/update/3/Firefox/14.0/20140318013849/Linux_x86_64-gcc3/en-US/beta/Linux%203.11.0-17-generic%20%28GTK%202.11.20%29/default/default/update.xml?force=1

The Thunderbird tests fail all over the place still, they also need a watershed at 12.0.
(Assignee)

Comment 7

3 years ago
Comment on attachment 8503398 [details]
Firefox 12.0 build1 blob

This ended up working well \o/
Attachment #8503398 - Attachment description: friday afternoon attempt at a blob → Firefox 12.0 build1 blob
(Assignee)

Comment 8

3 years ago
Created attachment 8504993 [details]
thunderbird 12.0.1 build1 blob

This one worked well too, except I'm pretty confused about the buildids. For example:
* https://aus4.mozilla.org//update/3/Thunderbird/9.0/20111220055216/Linux_x86_64-gcc3/ko/release/GTK%202.18./default/default/update.xml?force=1 returns an update with a buildid of 20120428123058
* The build notes (https://wiki.mozilla.org/Releases/Thunderbird_12.0.1/BuildNotes#Build_Data) list 20120420153206

I checked out one of the Linux builds and it gives me 20120428123058, so I'm guessing that the build notes are just wrong. Perhaps there was a build 2 that wasn't written down anywhere?
(Assignee)

Comment 9

3 years ago
Created attachment 8504995 [details]
early-release-comparison-urls-complete-filtered-6.out

So these tests are passing now, with some caveats:
* The GTK & Darwin deprecation stuff talked about in comment #6
* Thunderbird detailsURLs on aus3 are thinsg like "http://live.mozillamessaging.com/thunderbird/releasenotes?locale=ko&platform=linux-x86_64&version=12.0.1". We don't support platform substitution in Balrog, so I've reduced them to things like "http://live.mozillamessaging.com/thunderbird/releasenotes?locale=ko&version=12.0.1".
* SHA512 vs. sha512 (we had this for beta channel tests)
* uppercase vs. lowercase bouncer entries (had this in beta, too)

I _think_ that means we're all done here, but I wouldn't mind a second set of eyes. Here's the comparison log -- the detailsURLs/hashFunction/bouncerProduct parts were corrected in the scripts to make the output easier to parse.
(Assignee)

Comment 10

3 years ago
Given how the comparisons look I'm going to call this fixed unless we see issues during QE testing.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.