Closed Bug 842846 Opened 11 years ago Closed 11 years ago

Set up a build of Aurora-as-Beta about a week before merge, mail results of tbpl to release-mgmt/drivers

Categories

(Release Engineering :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: lsblakk, Unassigned)

References

Details

Dbaron called this out as an idea after we had a bit of post-merge headaches on bug 842772 and it seems like it might help us in the future if about a week before merge there was a scheduled builder that grabbed a known-good mozilla-aurora cset and then built it as though it was mozilla-beta, when complete it would send the results of the build to release-mgmt and release-drivers so that someone can look and ensure that we are aware of any test changes between the two branches before merge day.
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: catlee
I'd note that it's basically possible to do this by pushing an aurora (or whatever) tree to try; it just requires adding the line:
ac_add_options --enable-update-channel=beta
to the file build/mozconfig.common.override in the try push.

(The default mozconfigs set the update channel from an environment variable set from outside (from the buildbot config, I suppose); this overrides that default.)
(In reply to David Baron [:dbaron] from comment #1)
> I'd note that it's basically possible to do this by pushing an aurora (or
> whatever) tree to try; it just requires adding the line:
> ac_add_options --enable-update-channel=beta
> to the file build/mozconfig.common.override in the try push.
> 
> (The default mozconfigs set the update channel from an environment variable
> set from outside (from the buildbot config, I suppose); this overrides that
> default.)

If this can be automated against try - again with an email to drivers so that the results are announced - that would wfm.
(In reply to Lukas Blakk [:lsblakk] from comment #2)
> (In reply to David Baron [:dbaron] from comment #1)
> > I'd note that it's basically possible to do this by pushing an aurora (or
> > whatever) tree to try; it just requires adding the line:
> > ac_add_options --enable-update-channel=beta
> > to the file build/mozconfig.common.override in the try push.
> > 
> > (The default mozconfigs set the update channel from an environment variable
> > set from outside (from the buildbot config, I suppose); this overrides that
> > default.)
> 
> If this can be automated against try - again with an email to drivers so
> that the results are announced - that would wfm.

Is there a reason that someone on your team can't do this push to try?
BTW, try's settings are based on mozilla-central, so there may be differences between mozilla-central, aurora and beta.
(In reply to Rail Aliiev [:rail] from comment #4)
> BTW, try's settings are based on mozilla-central, so there may be
> differences between mozilla-central, aurora and beta.

I was concerned about that as well, but dbaron thought the mozconfig override in comment 1 would be sufficient to get the tests to treat the build as though it was beta.
(In reply to Ben Hearsum [:bhearsum] from comment #3)
> > If this can be automated against try - again with an email to drivers so
> > that the results are announced - that would wfm.
> 
> Is there a reason that someone on your team can't do this push to try?

Well this is a permanent, recurring event, so why not automate?  Also because the results being mailed to a wider distro list than just relman would make sure there were eyes on issues ahead of releases - we can include a dev list that dbaron is on, for example.
(In reply to Lukas Blakk [:lsblakk] from comment #6)
> (In reply to Ben Hearsum [:bhearsum] from comment #3)
> > > If this can be automated against try - again with an email to drivers so
> > > that the results are announced - that would wfm.
> > 
> > Is there a reason that someone on your team can't do this push to try?
> 
> Well this is a permanent, recurring event, so why not automate?  Also
> because the results being mailed to a wider distro list than just relman
> would make sure there were eyes on issues ahead of releases - we can include
> a dev list that dbaron is on, for example.

I really don't think this is special enough to require RelEng automation. We have systems setup that can do this. You can automate it yourself around them.
Blocks: 844683
A correction to comment 1, thanks to philor's discovery in bug 844683:  this would also need to include a version bump, for the reasons described in bug 844683 comment 2.  And possibly also something like the branding changes in https://hg.mozilla.org/try/rev/1c3af88b79c2
There are a few tiny problems with just automating a push to try, like the fact that unless someone fixes bug 725703 you either get no tests actually running on Android, or you test something other than a beta Android because you have to use nightly branding to get tests to run, and the fact that you have to know which talos suites don't run because trunk uses a different name than aurora does so tp5o doesn't exist in the talos.zip that your push uses, and you have to be willing to ignore all the noise from unsupported platforms that you have absolutely no way of avoiding, like Win8, and unsupported jobs that you have absolutely no way of avoiding, like the three implicit instead of explicit SpiderMonkey jobs that are shoved down your throat.

But most cycles, by the 5th week I'll know what does and doesn't work on try, so if you pipe the output of your automated push-to-try through me... oh, wait, this isn't ever going to happen, it's just going to be me manually pushing in the first and last week of every cycle that I'm around for.
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 725703
Resolution: --- → WONTFIX
Depends on: 861705
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.