Closed Bug 609981 Opened 10 years ago Closed 5 years ago

support release builds on TBPL

Categories

(Tree Management Graveyard :: TBPL, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: armenzg, Unassigned)

References

Details

This will help a lot specially because we run unit test for this branch on the minis.

To note that this page does not have that much activity and we might need to look at the results few days after the release builds have been created.

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox-Release

Thank you.

PS= We have other release branches but they are not as difficult to follow. Let's do this branch only for now. We can revisit later (or raise your voice if you want it all at the same time :D)
This won't be as trivial as just adding an entry to Config.js.  Here's why.  The build automation system increments the version number on a relbranch, and then tags that cset for build and release, and then pushes all of the revisions (which should usually be three) to mozilla-central.  But the actual builds happen on the first revision (the relbranch) itself.  For example, for 4.0b7, the following csets were pushed to mozilla-central:

    c0a8f2fd7d80
    ffxbld – Added tag FIREFOX_4_0b7_RELEASE for changeset 297086a0fb61. CLOSED TREE GECKO20b7_20101104_RELBRANCH
    d18572809e2f
    ffxbld – Added tag FIREFOX_4_0b7_BUILD1 for changeset 297086a0fb61. CLOSED TREE GECKO20b7_20101104_RELBRANCH
    297086a0fb61
    ffxbld – Automated checkin: version bump remove "pre" from version number for firefox 4.0b7 release on GECKO20b7_20101104_RELBRANCH CLOSED TREE FIREFOX_4_0b7_RELEASE FIREFOX_4_0b7_BUILD1 GECKO20b7_20101104_RELBRANCH

And the builds and tests happened on 297086a0fb61, which means that our usual code to map builds and tests to pushes won't work for this.
While fixing bug 602148 seems like the direct way to fix that, it would be considerably nicer to instead fix json-pushes to take an optional branch name, and then let Config pass one through to PushlogJSONParser. Otherwise, you're going to be paging back through all the furor of post-reopening pushes to default, looking for the one you're building from.
Depends on: 602148
Duplicate of this bug: 697721
Convenient: gavin fixed bug 602148.

Not so convenient: release automation no longer pushes something to default at the top (or anywhere else) in the tagging push.
(In reply to Phil Ringnalda (:philor) from comment #4)
> Convenient: gavin fixed bug 602148.
> 
> Not so convenient: release automation no longer pushes something to default
> at the top (or anywhere else) in the tagging push.

Excuse the probably obvious question, but why does it matter that we have something on default? Can't TBPL look at the tagged relbranch revision instead?
It doesn't actually matter, since even with a push to default, the jobs you want to see are not on that rev. I must just like to confuse myself, since I do it so often and so well.

tbpl works (ignoring usetinderbox=1) by fetching a pushlog, in your case something like https://hg.mozilla.org/releases/mozilla-beta/json-pushes?full=1&maxhours=24, and deciding which rev in each push would be the one which got builds in http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/file/480d152fc685/js/PushlogJSONParser.js#l29 (note our mistaken belief that the rev that gets builds will always be the tipmost rev on the default branch, in the name defaultTip), and fetching the results that the server-side part has scraped from builds-4hr.js for that rev.

So to work for releases (in the current world, where we're safe from being fooled by a rev on the default branch in the tagging push), that would need to have three cases: it's on default, it's defaultTip; it's on a branch which does not end in RELBRANCH, it's not defaultTip; it's on a branch which ends in RELBRANCH and it has a tag which ends in RELEASE, it's defaultTip.
This is redundant now, right?
(In reply to Ed Morley [:edmorley] from comment #7)
> This is redundant now, right?

I don't think so; we still don't have a way to view jobs triggered by Release Automation on TBPL.
Ah sorry, I mis-skim read and thought this (fairly old bug) was just asking for:
https://tbpl.mozilla.org/?tree=Mozilla-Release

So I'm guessing we need something like bug 741775, but for non-try (or at least mozilla-release)?
(In reply to Ed Morley [:edmorley] from comment #9)
> Ah sorry, I mis-skim read and thought this (fairly old bug) was just asking
> for:
> https://tbpl.mozilla.org/?tree=Mozilla-Release
> 
> So I'm guessing we need something like bug 741775, but for non-try (or at
> least mozilla-release)?

That would be a start, I think. I'm not 100% sure that the way the release jobs run fits in with TBPL's model because the 'revision' property isn't set. Releases can be tracked by looking for branch + version + build_number in the properties. For example, all jobs for 15.0b5 had the following:
* branch: release-mozilla-beta
* version: 15.0b5
* build_number: 1

The "branch" is the short branch name prepended with release- (usually one of release-mozilla-{beta,release,esr10}). The build_number is usually 1, but if we respin w/ the same version number we bump it.
Updating summary, because we don't have a "Firefox-Release" Tinderbox anymore.
Summary: Create a TBPL page for Firefox-Release Tinderbox page → support release builds on TBPL
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.