Closed
Bug 1262325
Opened 8 years ago
Closed 8 years ago
jamun's version_display.txt causes errors with relpro release sanity
Categories
(Release Engineering :: Release Automation: Other, defect)
Release Engineering
Release Automation: Other
Tracking
(firefox48 fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox48 | --- | fixed |
People
(Reporter: jlund, Assigned: rail)
References
Details
Attachments
(1 file)
58 bytes,
text/x-review-board-request
|
jlund
:
review+
rail
:
checked-in+
|
Details |
traceback: Traceback (most recent call last): File "release-runner.py", line 619, in main validate_graph_kwargs(queue, gpg_key_path, **kwargs) File "release-runner.py", line 450, in validate_graph_kwargs revision=kwargs["revision"], version=kwargs["version"]) File "release-runner.py", line 308, in validate_version (actual_version, version)) SanityException: In-tree version '46.0b8' doesn't match ship-it version '46.0' line in question: http://hg.mozilla.org/build/tools/file/default/buildfarm/release/release-runner.py#l304 context: I manually migrated m-b -> jamun following similar cmds found in https://docs.google.com/document/d/1udo4r0UB8de5NtpvVJHiKy41A2mGKZ8FhagcB4-q45s/edit#heading=h.1x2ypo497ka something like: $ cp -r jamun build/mozilla-release $ hg clone ${hg_url}/mozilla-beta build/mozilla-beta // essentially call migrate() $ python mozharness/scripts/merge_day/gecko_migration.py -c mozharness/configs/merge_day/beta_to_release.py --no-clean-repos --no-pull // manually commit and push migration to jamun repo url so either one of two things has to happen. 1) modify current merge logic[1] so it updates version_display.txt from something like 46.0b10 to 46.0. since our release-runner sanity check (and relpro automation) now expects it to be updated before the release starts. 2) modify release-runner sanity check[2] because it currently only factors betas [1] https://dxr.mozilla.org/mozilla-central/rev/17a0ded9bb99c05c25729c306b91771483109067/testing/mozharness/scripts/merge_day/gecko_migration.py#285 [2] http://hg.mozilla.org/build/tools/file/default/buildfarm/release/release-runner.py#l113
Reporter | ||
Comment 1•8 years ago
|
||
@rail - the version_display.txt version.txt dance confuses me. we expect them to be the 'next upcoming version before a release starts' in relpro world yes? And in current m-r bbot world it gets updated after? If so, I guess we need to modify merge scripts: part 1 from comment 0
Flags: needinfo?(rail)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → rail
Flags: needinfo?(rail)
Assignee | ||
Comment 2•8 years ago
|
||
(In reply to Jordan Lund (:jlund) from comment #1) > @rail - the version_display.txt version.txt dance confuses me. we expect > them to be the 'next upcoming version before a release starts' in relpro > world yes? And in current m-r bbot world it gets updated after? If so, I > guess we need to modify merge scripts: part 1 from comment 0 apparently we don't reset it for m-r
Assignee | ||
Comment 3•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/44569/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/44569/
Attachment #8738537 -
Flags: review?(jlund)
Assignee | ||
Comment 4•8 years ago
|
||
This is what it does: diff --git a/browser/config/version_display.txt b/browser/config/version_display.txt --- a/browser/config/version_display.txt +++ b/browser/config/version_display.txt @@ -1,1 +1,1 @@ -46.0b9 +46.0
Assignee | ||
Comment 5•8 years ago
|
||
I manually fixed it and pushed https://hg.mozilla.org/projects/jamun/rev/9277edef6ff5 (with a bad commit message)
Reporter | ||
Comment 6•8 years ago
|
||
Comment on attachment 8738537 [details] MozReview Request: Bug 1262325 - Reset mozilla-release version_display.txt on merge r=jlund a=release DONTBUILD https://reviewboard.mozilla.org/r/44569/#review41327 ::: testing/mozharness/scripts/merge_day/gecko_migration.py:374 (Diff revision 1) > what happens in each workflow, while allowing for things like > staging beta user repo migrations. > """ > dirs = self.query_abs_dirs() > + # Reset display_version.txt > + for f in self.config["version_files"]: neat. though I'm wondering if we should keep the same style as other branches by (1) only defining a "file" and "suffix" key and (2) using bump_version where we call bump_version like: self.bump_version(curr_version=self.get_version()[0], next_version=self.get_version()[0], curr_suffix=self.get_version()[1], next_suffix="") what do you think?
Attachment #8738537 -
Flags: review?(jlund)
Assignee | ||
Comment 7•8 years ago
|
||
I thought about using bump_version() but even now it looks a bit cryptic to me... Maybe I should just rename the config config variable to something like: "copy_files": [ { "src": "browser/config/version_display.txt", "dst": "browser/config/version.txt", }, On the other hand introducing a new entity is even worse... Let me come up with a new patch.
Assignee | ||
Comment 8•8 years ago
|
||
Comment on attachment 8738537 [details] MozReview Request: Bug 1262325 - Reset mozilla-release version_display.txt on merge r=jlund a=release DONTBUILD Review request updated; see interdiff: https://reviewboard.mozilla.org/r/44569/diff/1-2/
Attachment #8738537 -
Flags: review?(jlund)
Reporter | ||
Comment 9•8 years ago
|
||
Comment on attachment 8738537 [details] MozReview Request: Bug 1262325 - Reset mozilla-release version_display.txt on merge r=jlund a=release DONTBUILD https://reviewboard.mozilla.org/r/44569/#review41339
Attachment #8738537 -
Flags: review?(jlund) → review+
Assignee | ||
Comment 10•8 years ago
|
||
I tried to use bump_version and get_version, but it becomes really unreadable. get_version splits things by ".", so I need to split by "b" then to construct proper parameters to bump version. It may become very fragile in the future. I found copying files is less painful and more straight forward. IF we need this functionality for other branches, we can refactor the action into a separate function.
Reporter | ||
Comment 11•8 years ago
|
||
(In reply to Rail Aliiev [:rail] from comment #10) > I tried to use bump_version and get_version, but it becomes really > unreadable. get_version splits things by ".", so I need to split by "b" then > to construct proper parameters to bump version. It may become very fragile > in the future. I found copying files is less painful and more straight > forward. IF we need this functionality for other branches, we can refactor > the action into a separate function. wfm
Assignee | ||
Comment 12•8 years ago
|
||
Comment on attachment 8738537 [details] MozReview Request: Bug 1262325 - Reset mozilla-release version_display.txt on merge r=jlund a=release DONTBUILD https://hg.mozilla.org/integration/mozilla-inbound/rev/07efe4d65e40
Attachment #8738537 -
Flags: checked-in+
Comment 13•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/07efe4d65e40
You need to log in
before you can comment on or make changes to this bug.
Description
•