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

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect)

Description

[Jordan Lund (:jlund)]

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

Comment 1

[Jordan Lund (:jlund)]

@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

Comment 2

[Rail Aliiev [:rail]]

(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

Comment 3

[Rail Aliiev [:rail]]

Attachment: 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/

Comment 4

[Rail Aliiev [:rail]]

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

Comment 5

[Rail Aliiev [:rail]]

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

Comment 6

[Jordan Lund (:jlund)]

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?

Comment 7

[Rail Aliiev [:rail]]

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.

Comment 8

[Rail Aliiev [:rail]]

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/

Comment 9

[Jordan Lund (:jlund)]

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

Comment 10

[Rail Aliiev [:rail]]

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.

Comment 11

[Jordan Lund (:jlund)]

(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

Comment 12

[Rail Aliiev [:rail]]

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

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/07efe4d65e40