jamun's version_display.txt causes errors with relpro release sanity

RESOLVED FIXED

Status

Release Engineering
Release Automation
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: jlund, Assigned: rail)

Tracking

other
Dependency tree / graph

Firefox Tracking Flags

(firefox48 fixed)

Details

MozReview Requests

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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

2 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

2 years ago
Assignee: nobody → rail
Flags: needinfo?(rail)
(Assignee)

Comment 2

2 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

2 years ago
Created attachment 8738537 [details]
MozReview Request: Bug 1262325 - Reset mozilla-release version_display.txt on merge r=jlund a=release DONTBUILD

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

2 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

2 years ago
I manually fixed it and pushed https://hg.mozilla.org/projects/jamun/rev/9277edef6ff5 (with a bad commit message)
(Reporter)

Comment 6

2 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)
(Reporter)

Updated

2 years ago
Blocks: 1262000
(Assignee)

Comment 7

2 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

2 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

2 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

2 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

2 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

2 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

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/07efe4d65e40
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.