Closed Bug 505318 Opened 11 years ago Closed 9 years ago

[Tracking bug] kicking off a release shouldn't require a reconfig

Categories

(Release Engineering :: General, defect, P4)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: catlee, Assigned: armenzg)

References

Details

(Whiteboard: [automation][oldbugs])

Having all of the parameters for a release stored in release_config.py means that do start a release you need to:
- Push changes to release_config.py
- ssh to production-master, pull and update changes
- reconfig production-master

This isn't easily automated (thinking of production-master reconfiguring itself makes me shudder), and there's also the risk of pulling in unwanted changes from buildbot-configs just to get the updated release configs.  The current method also becomes a bit complicated when considering releases on multiple branches.

We should continue to have the release parameters stored in version control, but figure out a way to avoid the ssh and reconfigure step.

One idea is to have the release configs checked out on the build slave, and set as build properties.  Which config file to read could be a function of which release branch is triggered, or maybe listed in the 'files' parameter of a sendchange event.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Whiteboard: [automation]
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Priority: P3 → P4
I don't think I will manage to get this done before the end of the quarter.

I agree with catlee's approach.

Let's also wait to see what the release automation looks like after we upgrade to 0.8.x
Depends on: 553300
Whiteboard: [automation] → [automation][oldbugs][triagefollowup]
After talking with bhearsum and catlee last week there few things that are to be fixed. The general opinion is that this bug should close this bug because there is no workable actions on this bug OR turn this into a tracking bug.

@triagefollowup can we close this bug and/or turn into a tracking bug?

As a summary:
#############
Each builder on a release should be able to pull the information from buildbot-configs rather than being passed as parameters to each builder's factory.

Besides that, the FTP poller has to be fixed. 

After the work that bhearsum is doing with tagging and l10n we won't depend on a reconfig anymore.
Depends on: 508896
(In reply to comment #3)
> After the work that bhearsum is doing with tagging and l10n we won't depend on
> a reconfig anymore.

If that's true, then you can dupe this bug to one of those (and provide a link to the other.
(In reply to comment #4)
> (In reply to comment #3)
> > After the work that bhearsum is doing with tagging and l10n we won't depend on
> > a reconfig anymore.
> 
> If that's true, then you can dupe this bug to one of those (and provide a link
> to the other.

I think Armen means that those steps won't depend on a reconfig anymore. We still need one for all other builders.
Armen,

Can you follow up with Ben to get the issue settled?  It sounds like you should create a tracking bug (or find one if it exists) and create a followup bug for the new issues.

The make both this bug and the new one block the tracker.  That will let you close this bug and we will still have history and dependency tree data
(In reply to comment #6)
> Can you follow up with Ben to get the issue settled?  It sounds like you should
> create a tracking bug (or find one if it exists) and create a followup bug for
> the new issues.

Let's make this bug the tracking bug. Armen can get new bugs filed for the remaining issues and make them dependencies of this bug.
Summary: kicking off a release shouldn't require a reconfig → [Tracking bug] kicking off a release shouldn't require a reconfig
Whiteboard: [automation][oldbugs][triagefollowup] → [automation][oldbugs]
Priority: P4 → P5
triage: If I file the required dependent bugs would it then be good to drop the [oldbugs] from the whiteboard?
Whiteboard: [automation][oldbugs] → [automation][oldbugs][triagefollowup]
(In reply to comment #8)
> triage: If I file the required dependent bugs would it then be good to drop the
> [oldbugs] from the whiteboard?

Well, it's still going to be an oldbug. The bug # is still going to determine that. But yes, please do file any outstanding dependent bugs.
Whiteboard: [automation][oldbugs][triagefollowup] → [automation][oldbugs]
@triagefollowup

I won't get to this.

This is a whole one quarter goal in itself and cannot be hit this quarter even if everything else was dropped to work on it.

It pretty much requires every single builder to behave the same way as the tagging and L10n repacks builders which checkout buildbot-configs to grab information from mozilla/release-firefox-$branch.py files (IIUC).

It also requires to find a solution to fix the L10n pollers (the ones that trigger partner repacks) and the poller for triggering postsigning builders.
Whiteboard: [automation][oldbugs] → [automation][oldbugs][triagefollowup]
Priority: P5 → P4
(In reply to comment #10)
> It pretty much requires every single builder to behave the same way as the
> tagging and L10n repacks builders which checkout buildbot-configs to grab
> information from mozilla/release-firefox-$branch.py files (IIUC).
> 
> It also requires to find a solution to fix the L10n pollers (the ones that
> trigger partner repacks) and the poller for triggering postsigning builders.

As it stands, this bug is a tracking bug with no dependencies, so I'm closing it.

*However*, Armen, can I please ask you to file specific bugs for fixing up the pollers and builders that are outstanding. Make them block the new hg-automation tracking bug rather than this one, please.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [automation][oldbugs][triagefollowup] → [automation][oldbugs]
I filed bug 633304 and bug 633307 to track this.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.