Closed
Bug 748773
Opened 13 years ago
Closed 9 years ago
read revisions required for a release from a common file
Categories
(Release Engineering :: Release Automation: Other, defect, P3)
Release Engineering
Release Automation: Other
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bhearsum, Unassigned)
References
Details
Various parts of the release automation update to particular revisions of different repositories as part of their set-up. This includes buildbot-configs, buildbotcustom, tools, the source repository (eg, mozilla-beta), and l10n repositories.
When we start doing rapid betas, we'll quickly clog up a bunch of these repositories if we don't change the way we do things. Additionally, it should help the reconfigless release effort to have a predictable place to read these from.
Here's a rough outline of what needs to happen:
1) Create a new repository to store these files
2) Create a script which logs all of these revisions to a file at the start of a release. For buildbot-configs, buildbotcustom, and tools, we probably take the tip of production/production-0.8/default. For the source repo and l10n revisions, we use what's in the release config/l10n changesets.
3) Run the script at the start of a release
4) Convert all builders that read revisions or tags from a file to use this new file, instead.
After writing all of that....I'm wondering what the point of putting the source and l10n revisions in this new file is, other than it being a central place to log them all. We've already got them in the release config!
Reporter | ||
Updated•13 years ago
|
Priority: -- → P3
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Reporter | ||
Comment 1•9 years ago
|
||
Release promotion will be data driven and pass along the necessary information all steps rather than rely on checked in versions.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•