Closed Bug 1071847 Opened 10 years ago Closed 10 years ago

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

Categories

(Release Engineering Graveyard :: Applications: Balrog (backend), defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

References

Details

Attachments

(3 files)

Just like bug 1049550, but for the release channel.
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: nobody → bhearsum
(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
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.
(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.
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.
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
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?
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.
Given how the comparisons look I'm going to call this fixed unless we see issues during QE testing.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: