Closed
Bug 664476
Opened 14 years ago
Closed 13 years ago
mozharness release configs should be more generic
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 675286
People
(Reporter: mozilla, Assigned: mozilla)
References
Details
(Whiteboard: [releases][automation][mozharness])
Attachments
(2 files)
24.37 KB,
patch
|
Details | Diff | Splinter Review | |
7.57 KB,
patch
|
Details | Diff | Splinter Review |
As we currently have it, we need to create new config files every 6 weeks and update configs to point to those new config files.
Instead, if we have mozilla-beta and mozilla-release -named config files, we can just bump versions in there.
This isn't hard, but I wanted to wait until the glut of releases are out of the way, and after I get back from vacation, to do this.
Assignee | ||
Comment 1•13 years ago
|
||
Rail's solving the naming in bug 574764, but we're going to have to bump versions and tags in config files every release.
Abstracting that out and passing in --version would help avoid that.
However, that would probably mean we either need a dummy --version in nightlies, or we need different args passed in for release vs nightly builds.
Depends on: mobile-0.8-releases
Summary: mozharness + mobile 0.7 release configs should not be version-named → mozharness release configs should be more generic
Assignee | ||
Comment 2•13 years ago
|
||
This patch:
* removes all existing deb signing configs for mozharness
* creates [staging_]release_mozilla-{beta,release}.py
** these have VERSION and BUILDNUM at the top for easy editing.
** point to the new l10n changesets json files created in bug 574764
** remove the base_work_dir that was uglifying things on s-m-m (this will force you to run the script inside of the scratchbox directory tree, but we were already doing that).
* fixes the mis-scoped fh.close() in parse_config_file() that was breaking .py config files.
We no longer have a nightly deb signing config because we haven't been running maemo5 single locale repacks for months.
Attachment #545271 -
Flags: review?(lsblakk)
Assignee | ||
Comment 3•13 years ago
|
||
I spent more time on this than I should have, but this should hopefully make things nicer if we have to extend Maemo support.
* mozilla-beta and mozilla-release branches only, no nightlies.
* a couple of workdir/baseWorkDir fixes that cleans things up in s-m-m:/scratchbox/users/cltbld/home/cltbld
* specifies staging-deb-BRANCH directories for staging, so we don't clobber on production's toes.
* adds the branch to the release factory, so we stop getting deb-unknown directories
Attachment #545272 -
Flags: review?(lsblakk)
Assignee | ||
Comment 4•13 years ago
|
||
Tested here:
http://staging-mobile-master.build.mozilla.org:8011/waterfall
Dependent on bug 574764 landing first, due to the l10n-changesets pointing to the new not-yet-landed locations.
Still need to deal with comment 1; a quick-n-dirty first step might be moving to .py multilocale configs and specifying versions/tags at the top. This will still require editing the configs every release, but will be a faster edit.
Assignee | ||
Comment 5•13 years ago
|
||
Hm, with no maemo5-gtk repacks, we really only need to create repos for multi+en-US.
These should still work, but they'll go red and/or throw errors.
Assignee | ||
Comment 6•13 years ago
|
||
Comment on attachment 545271 [details] [diff] [review]
clean up deb mozharness configs
We may be moving maemo to tier 3.
Attachment #545271 -
Flags: review?(lsblakk)
Assignee | ||
Updated•13 years ago
|
Attachment #545272 -
Flags: review?(lsblakk)
Assignee | ||
Comment 7•13 years ago
|
||
Fixed in bug 675286.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•