+++ This bug was initially created as a clone of Bug #1713655 +++

+++ This bug was initially created as a clone of Bug #1712538 +++

Tracking bug for 91.0

according to the notes, 1 week prior to merge day (i.e. this week), we should do no-op trial runs, wnp pages (if needed).

I did the mozilla-beta trial run and resulted in this diff

I did the esr91 trial run and resulted in this error <- note, I needed to adjust the notes from bump-esr -> bump-esr91

I did the esr78 trial run and resulted in this diff

lastly I asked in #releaseduty about a no-op trial run for: release -> esr; :aki indicated that is probably not needed.

We do need WNP for this release, so I have filed Bug 1722366.

I don't think we want to run the bump-esr91 task -- that'll bump us to esr 91.1.0, and we want to ship esr 91.0.0 (no bumping needed).

It does look like we have a beta version display in esr91, however, so maybe we do want the release->esr run, unless someone is going to bump those manually.

thanks for the context :aki.

I did a release-to-esr run on mozilla-release and this resulted in an error:

File "/app/lib/python3.8/site-packages/mozilla_version/gecko.py", line 228, in parse
    return super(GeckoVersion, cls).parse(
  File "/app/lib/python3.8/site-packages/mozilla_version/version.py", line 56, in parse
    return cls(**kwargs)
  File "<attrs generated init mozilla_version.gecko.GeckoVersion>", line 15, in __init__
  File "/app/lib/python3.8/site-packages/mozilla_version/gecko.py", line 484, in __attrs_post_init__
    super(_VersionWithEdgeCases, self).__attrs_post_init__()
  File "/app/lib/python3.8/site-packages/mozilla_version/gecko.py", line 223, in __attrs_post_init__
    raise PatternNotMatchedError(self, patterns=error_messages)
mozilla_version.errors.PatternNotMatchedError: "90.0.3esr" does not match the pattern: "90" is not a valid ESR major number. Valid ones are: (10, 17, 24, 31, 38, 45, 52, 60, 68, 78)
exit code: 1

It appears we need to update mozilla_version. We have updated this already as per the most recent commit. Quite possibly we need to figure out how to require mozilla_version 0.5.4 instead of whatever version we currently use.

AFAIK we already rolled that out, given https://github.com/mozilla-releng/shipit/blob/main/api/requirements/public.txt#L77 but based on https://github.com/mozilla-releng/shipit/commit/325c49df12b89ba9df235493834152adb48bede8, it's only on main, but not on production yet.

Found in Ship-it staging - https://treeherder.mozilla.org/jobs?repo=try&revision=05472611bba745ac46cde99fac59f76666970459 was the previous staging release for ESR91; looking at the commit history there, I think jcristau might've tweaked esr91 with some in-tree tweaks to make that work. Some of those might've ended up as patches in esr91 in the meantime, I believe.

ok, I see that when we fail to run this, we hg clone mozilla-unified; hg up esr78; so if we landed code on esr91 (or beta 91, etc.) then we will not have access to it in this task.

that is one theory

• Central -> beta dry run task is here spawning the actual task

• esr dry-run - https://firefox-ci-tc.services.mozilla.com/tasks/ZucqRfWzTQe_s0SH-jcpWQ spawning https://firefox-ci-tc.services.mozilla.com/tasks/bqcnRpJjRqa_7N8w2Kd8XQ#artifacts. Diff looks good - https://firefoxci.taskcluster-artifacts.net/bqcnRpJjRqa_7N8w2Kd8XQ/0/public/logs/esr78.diff
• esr actual run for esr78 is this while esr91 is this

mozilla-beta is open again at 92.0b1
mozila-central is bumped to 93.0a1

the esr78 and esr91 bumps have worked.

Currently all builds are running, then tests will run. All decision tasks/linters look good.