After talking to Nate Lust it seems that he can deploy his existing swoosh-based search service on a Nebula instance. That will give us search by ticket branch (and maybe tag?) now for only the cost of deployment configuration.
GitHub provides code search, but it's not 100% usable here because it doesn't seem to work across an organization and only tracks master.
The documentation hub that I mentioned in SQR-011 might be a good long-term solution for this (I'll update that technote to specifically mention code search and this ticket). The DocHub will be Elasticsearch (i.e., robust, web-scale search) fronted by an API. This will allow search to happen from many contexts (e.g., from the DocHub landing page, or from the SQUASH dashboard, code documentation sites, etc.).
Integrating code search in DocHub will be ideal in terms of having shared infrastructure, and having one-fewer webpage for folks to know about.
The DocHub will be able to naturally deal with versioning as a search facet since this concept is also used in our documentation.
I'm not sure about tooling to provide syntax analysis in elasticsearch. GitHub doesn't do this in their elasticsearch, for example. Keep in mind that code search is related to documentation search, and the documentation (API reference) does clearly distinguish functions, classes, etc. The API reference is also potentially tagged with each EUPS and CI 'build'. So perhaps there's some useful synergy in code search and doc search we can use here.
As for a command-line search service, we could certainly have a command line client to the web search RESTful API.
The tool for searching the currently 'setup' local stack would be quite distinct from this. But is there a need for a custom tool compared to, say, grepping the checked-out lsstsw directory? I see that last use-case as having the least profitability from DM-specific tooling. I could be wrong on this, though.