1717535 - Add mozilla-esr91 to searchfox

Status: RESOLVED FIXED

(Webtools :: Searchfox, task)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

We need to add esr91 to the list of branches indexed by searchfox

see prior art of ESR 78 in Bug 1646118

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Marking the logistical dependencies of:

• bug 1717530 - there needs to be a branch to check out
• bug 1717533 - this is the treeherder bug which isn't strictly speaking required, it's all the taskcluster-y underpinnings that treeherder depends on, but practically speaking if we can't see jobs for the branch in treeherder we also can't figure stuff out

Comment 2

[Julien Cristau [:jcristau]]

Searchfox index jobs are now running on esr91, e.g. https://treeherder.mozilla.org/jobs?repo=mozilla-esr91&revision=b8dfd5de99f86d8cc28d301bba96a35c06bd376d&searchStr=searchfox

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Julien Cristau [:jcristau] from comment #2)

Searchfox index jobs are now running on esr91, e.g. https://treeherder.mozilla.org/jobs?repo=mozilla-esr91&revision=b8dfd5de99f86d8cc28d301bba96a35c06bd376d&searchStr=searchfox

Yay! Thanks for getting that shovel ready via the .cron.yml changes in https://hg.mozilla.org/releases/mozilla-esr91/rev/d88ba22ed4b5bc069e38e15448bb1ffc3447f964#l1.1 !

I'll poke some buttons.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

My plan is to move mozilla-esr68 and comm-esr68 into config3.json (which only runs when manually triggered) from config2.json (which runs on the regular) where they live now because per https://wiki.mozilla.org/Release_Management/Calendar ESR68 ceased to be a notable thing about a year ago.

This will require changing the ELB rules, and I will do that. Sequence plan here is:

• Commit 1: Add ESR68's to config3, adjust blame generation scripts impacting config1 so it knows about esr91.
  • Done: https://github.com/mozsearch/mozsearch-mozilla/pull/143
• Trigger config3 indexer.
  • Done: config3 has esr68 in there
• Config1 indexer updates gecko-blame as part of utc22 run.
  • Done as part of https://github.com/mozsearch/mozsearch-mozilla/pull/143
  • The utc22 web-server's mozilla-central blame directory now shows a populated esr91 branch
• Adjust ELB rules following completion for moved esr68's and new esr91 (which will initially be a 404)
  • Done: mozilla-esr68 and comm-esr68 are now pointed at release3-target and I've added mozilla-esr91 and comm-esr91 (which will not yet exist) to point at release2-target for both http and https. (Note that the editing process was actually mutating the existing release2-target rules and adding a new set of release3-target rules because the release3-target already had 5 path matches in the rule.)
• Commit 2: Add ESR91 to config2, remove esr68's from config2, updating root help.html listing.
  • Done: https://github.com/mozsearch/mozsearch-mozilla/pull/144
• Re-run config2.
  • Done: completed and esr91 content is now visible.
• Let config1 eventually update the help file.
  • Done: The root searchfox.org lists esr91 and when you click on it, it works.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Thank you for taking care of this! Also sorry that this conceptually simple change requires so much planning, I wish it were less onerous.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Thank you for taking care of all of this before and being so diligent about documenting and improving the process and helping me learn more about all of this with your attentive assistance in my other pull requests like for pine! Thanks to your improvements, the setup is far from onerous. (And most importantly, it's easy to know how to get started, which is often the hardest part of anything.)

I have the long bulleted list there mainly as a planning checklist for my/others' benefit[1] and because I wanted to structure things so that we're ratcheting our way to things working and if I get delayed between steps or something fails, I haven't regressed esr68, etc.

1: In particular, it's handy from my perspective to:

• Make sure I haven't missed any subtleties that my brain normally glosses over.
• Help me do any documentation improvements later on, or if I fail to do that, have an artifact that can be consulted.
• Make it easier to understand how we could automate this in the future, or recognize when maybe not automating things is fine and the safest approach.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

I think things are working now. As an experiment I updated comment 4 as I went along and that at least seemed like a better place than my local markdown notes.

Note that at some point I assume comm-esr91 will become a thing and we can address that then.