Closed Bug 1577406 Opened 1 year ago Closed 4 months ago

Add comm-esr68 to searchfox

Categories

(Webtools :: Searchfox, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: standard8, Assigned: kats)

Details

As DXR is heading to no longer be supported, could comm-esr68 be added to searchfox please?

I see at https://github.com/mozsearch/mozsearch-mozilla/blob/master/config.json#L36 that https://github.com/mozilla/releases-comm-central is the git searchfox uses for comm-central. Is there a specific branch in place there for comm-esr68?

One concern is we're experiencing some non-linear indexing scaling issues right now that are tracked on bug 1567724, but I understand that comm-central is a tiny index because I guess we only perform analysis for the non-mozilla-central parts? That probably means we don't have to address bug 1567724 as a pre-req, but in the event anyone working on Thunderbird wants to get more involved in Searchfox... that's a great way! ;)

Flags: needinfo?(standard8)

I'm going to pass the question onto Magnus since he'll likely to know the answer or who needs pinging to set that up.

Flags: needinfo?(standard8) → needinfo?(mkmelin+mozilla)

https://github.com/mozilla/releases-comm-central seems to be different from https://github.com/mozilla/gecko-dev.
I don't know how these are setup, but there doesn't seem to be any suitable branches on the comm-central one. gecko-dev has a "esr68" branch.

Adding a few people who could know.

Flags: needinfo?(mkmelin+mozilla)

The right place to look seems to be https://github.com/mozilla/releases-comm-central, but that doesn't have a branch for 68 (although it does have recent commits so something is keeping that up-to-date). Does anyone know how that gets updated?

The git branch may end up being moot. I believe :emilio is looking into making searchfox know how to use git-cinnabar to access mercurial instead of requiring a repo_sync daemon to do it. No guaranteed timeline on that, though. Also, in related news, we've managed to improve the indexing time of that secondary job. (It's still slower than it should be, but it's down from 11+ hours to 6+ hours.)

(In reply to Patrick Cloke [:clokep] from comment #4)

The right place to look seems to be https://github.com/mozilla/releases-comm-central, but that doesn't have a branch for 68 (although it does have recent commits so something is keeping that up-to-date). Does anyone know how that gets updated?

FYI this is probably happening via the vcs-sync service that mozilla runs. :dhouse would be the contact point for that. If they can add a branch for 68 then we should be easily be able to pull that for searchfox purposes.

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #5)

The git branch may end up being moot. I believe :emilio is looking into making searchfox know how to use git-cinnabar to access mercurial instead of requiring a repo_sync daemon to do it.

At the moment we're still relying on the vcs-sync setup so that we end up with git hashes that are compatible with what others are using. If/when vcs-sync switches entirely to cinnabar for syncing then we won't need it anymore as we can run cinnabar and do the conversions ourselves.

As searchfox now seems to support various mozilla-esr repos (back to esr-17) following Bug 1617567, are we any closer to adding at least 68 (and maybe 60)?

comm-central ESR repos are in a different bucket from mozilla-esr repos, because the comm-central ESR repos don't have existing github clones/branches whereas the mozilla-esr repos do. But anyway, yes, we can do this now because we have improved cinnabar support in searchfox to the point where we can handle hg-only repos.

I can try to stand this up later this week or next week. Also just so we're clear, the c-c ESR repos will just have text search and blame, and no mozilla/ subfolder like c-c master does, because I don't think we have a way to know which version of m-c to pull in.

Assignee: nobody → kats

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #8)

I can try to stand this up later this week or next week. Also just so we're clear, the c-c ESR repos will just have text search and blame, and no mozilla/ subfolder like c-c master does, because I don't think we have a way to know which version of m-c to pull in.

It is a fairly straightforward mapping for mozilla, for comm-esr68 it would map to mozilla-esr68, for comm-esr60 it would map to mozilla-esr60, etc.

Though I think the priority is to have the comm ESR repos there (because, as far as I am aware, the blame doesn't work properly in the mozilla/ subfolder at the moment).

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.