This removes qdrant from this codebase entirely.
All the docker images, dependencies, (dead) usage in code.
My understanding is that we don't use this feature and never properly rolled it out.
Test plan:
CI passes and code review from owners.
We no longer need this endpoint. Also found a few other things related to internalapi on the way that could use a cleanup.
## Test plan
Integration tests should verify that conf works just as before.
In the upcoming release, we will only support gRPC going forward. This PR removes the old HTTP client and server implementations and a few leftovers from the transition.
This PR adds support for automatic retries in the frontend configuration grpc client.
I have gone through the frontend protobuf file and marked all the methods I thought were idempotent (we can't inspect this using the go protobuf packages, but I thought this was nice for documentation).
I then wrapped the basic frontend grpc client with an "automaticRetryClient" that uses the default retry policy that was defined in https://github.com/sourcegraph/sourcegraph/pull/59095. See that PR for more details. All the methods are idempotent, so they all get the new retry logic.
## Test plan
CI
Cody no longer needs it and it is obsolete now!
Since App added a non-insignificant amount of new concepts and alternative code paths, I decided to take some time and remove it from out codebase.
This PR removes ~21k lines of code. If we ever want parts of single binary (app), the redis kv alternatives, or the release pipeline for a native mac app back, we can look back at this PR and revert parts of it, but maintaining 21k lines of code and many code paths for which I had to delete a surprisingly small amount of tests justifies this move for me very well.
Technically, to some extent SG App and Cody App both still existed in the codebase, but we don't distribute either of them anymore, so IMO we shouldn't keep this weight in our code.
So.. here we go.
This should not affect any of the existing deployments, we only remove functionality that was special-cased for app.
Now that we're running go 1.21, we can take advantage of its new features. This cleans up a few utilites that have since been included in the standard library.
Brings something like https://github.com/sourcegraph/cody/pull/1192 to Sourcegraph's web client, injected as a new `telemetryRecorder` in `PlatformContext`. Because we want to use the only non-deprecated way to make GraphQL requests, Apollo clients, a global events recorder is not provided ([thread](https://sourcegraph.slack.com/archives/C01C3NCGD40/p1698376463350449)) - the shared one can only retrieved from `PlatformContext`.
In non-`web` platforms (`client/browser`) the recorder is currently set to a no-op recorder that errors upon use, as for this PR intended for backport, we only want to add some usages to `web` for Cody events.
To start off, this change adds some new usage of this on a rather out-of-the-way section `permissions-center`, tested manually below.
Closes https://github.com/sourcegraph/sourcegraph/issues/56920
* log: remove use of description paramter in Scoped
* temporarily point to sglog branch
* bazel configure + gazelle
* remove additional use of description param
* use latest versions of zoekt,log,mountinfo
* go.mod
support single-program execution
Now, `sg start single-program` starts a single-binary local dev server. This is similar to Cody app, but instead of using a Tauri desktop app UI and limiting to only Cody-related functionality, it runs a full Sourcegraph instance and lets you access it through your web browser. It is useful for local dev because it's less resource-intensive and has faster recompile/relink times than `sg start` (which runs many processes).
This removes an unnecessary internal endpoint. Basically,
`schema.ClientConfiguration` is the only consumer of `conf.*Configs()`,
which are the only consumers of `internalClient.ExternalServiceConfigs`,
which just hits the database and pulls the URL off the config.
So, rather than calling an internal API from `frontend`, which is just
served by `frontend`, this PR updates `schema.ClientConfiguration` to
just hit the database directly for this information, allowing us to get
rid of one of the few remaining internal APIs.
This is an API that was slated to be converted to gRPC, so I'd rather
not convert things we can just delete.
Context: I am working towards us having two definitions in our codebase:
1. "App" -> the _deployment type_ of Sourcegraph you use on your local
machine.
2. "Single binary" -> App is always single-binary, but not all
single-binaries are App. In the future, all Sourcegraph services will be
"single binary" and so this term will exist in our codebase to refer to
code that is used when ran in a "single binary" setting.
---
Stacked on top of #49064
This change introduces `deploy.IsApp()` and `deploy.IsSingleBinary()`
helpers that do not need to be fed the deployment type.
## Test plan
Existing tests
Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>
Previously one needed to specify all of these env vars in order to run the `sourcegraph` App:
```
SRC_FRONTEND_INTERNAL=localhost:3090
EXECUTOR_FRONTEND_PASSWORD=asdf
```
After this, just running `sourcegraph` is enough.
* `EXECUTOR_FRONTEND_PASSWORD`, although it is ignored in the App deployment type,
must be set to _something_ otherwise a validation error will occur.
Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>
We should seek to avoid damaging email reputations by validating if emails are verified before sending certain types of potentially high-frequency, non-essential emails to user primary emails, in this change:
- Account update notifications
- Code monitors
In practice, at the moment only builtin auth signups will create accounts that have unverified primary emails. External service accounts are created with primary emails already verified, and so are those created with the createUser mutation (which I am hoping to change in #46187).
Today, a user could create a user with an invalid email, and then proceed to set up a code monitor that accidentally sends large numbers of emails that all bounce, which has implications for Cloud's managed SMTP services.
Co-authored-by: Joe Chen <joe@sourcegraph.com>
phabricator: Simply repo create
We no longer need to perform a remote call from repo-updater in order to
create a Phabricator repo, we can simply call the DB directly. This
removes the need for an internal handler in frontend to talk to the DB
as well as the client code to call this handler.
Hasn't been used in production for 30 days. No references to the
internal client. Outside of that no matches for the URL path in
Sourcegraph.
Test Plan: go test
Hasn't been used in production for 30 days. No references to the
internal client. Outside of that no matches for the URL path in
Sourcegraph.
Test Plan: go test
Now that we require go1.18, we can use a builtin type alias for
"interface{}": "any". I've updated all code except lib, which can be
imported by external modules. That is currently pinned at go1.16.
Additionally I had to rerun generate since rewriting generated go code
will fail CI.
find -name '*.go' | xargs gofmt -s -r 'interface{} -> any' -w
git checkout lib
go generate ./...
Test Plan: CI will exercise that the code still compiles. Otherwise this
is a noop.
