We created a decoder that was never used, but the package is otherwise
unused. It recently had a CVE, so this just removes it so it's no longer
part of our security surface area.
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.
Use [esbuild](https://esbuild.github.io/) instead of Webpack for builds of `client/web`, for faster builds (dev and prod) and greater dev-prod parity. This PR completely removes all use of Webpack in this repository.
`client/web` is the last build target that still uses Webpack; all others have been recently migrated to esbuild. Most devs here have been using esbuild for local dev of `client/web` for the last 6-12 months anyway. The change here is that now our production builds will be built by esbuild.
All sg commands, integration/e2e tests, etc., continue to work as-is. The bundlesize report will take a while to stabilize because the new build products use different filenames.
## Benchmarks
Running `pnpm run generate && time pnpm -C client/web run task:gulp webBuild` and taking the `time` output from the last command:
- Webpack: 62.5s
- esbuild: 6.7s
Note: This understates esbuild's victory for 2 reasons: (1) because esbuild is building both the main and embed entrypoints, whereas Webpack only builds the main entrypoint in this benchmark) and (2) because a lot of it is in the fixed startup time of `gulp`; esbuild incremental rebuilds during local dev only take ~1s.
## Notes
We no longer use Babel to produce web builds (we use esbuild), so we don't need any Babel plugins that optimize the output or improve browser compatibility. Right now, Babel is only used by Jest (for tests) and by Bazel as an intermediate step.
We were not using [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) reports, but they were running (asynchronously) on each build, which caused occasional build flakes and added a moderate amount of complexity to our CI.
The reports do have value in theory, but we were not actually consulting the reports.
* use single-file entrypoints for browser ext webpack config
This is more standard and puts more of the config in code not config. This also makes it easier to support esbuild builds for the browser extension (esbuild does not support multiple sources for an entrypoint, because such behavior is undefined except by webpack, and who knows what it does).
* use different file basenames for native & phabricator integrations
This makes it easier (in the future) to simplify our bundler config for the browser extension because some bundlers (esbuild via Bazel, for example) do not support 2 entrypoints with the same file basename.
* name entrypoint bundles after their entrypoint, not a custom name
This removes another source of "names" and also makes it so that the browser extension can be built by esbuild via Bazel in the future (which does not support renaming entrypoints).
Also remove Webpack auto-reloading because its implementation depended on this. There is a workaround, but the intent is to remove Webpack for bext builds, so it's not worth keeping it.
Also sanitize HTML more strictly. Previously we allowed SVG and `data:`
URIs in some cases (for some functionality from the legacy Sourcegraph
extension API). This is no longer needed, and getting stricter in HTML
sanitization is generally good.
## Test plan
Test callers of renderMarkdown in UI.
Co-authored-by: Juliana Peña <me@julip.co>
- Remove support for toggling native tooltips from the browser
extension. This let users choose to keep the browser extension installed
and partially active on GitHub but not show Sourcegraph's hovers. This
functionality is less important now that GitHub's new code nav no longer
uses hovers. For old GitHub Enterprise server instances (and GitHub.com
users who have not enabled the new code view), users can disable the
browser extension if they want to disable Sourcegraph's hover
functionality.
- Remove hover alerts, which were used to warn users that the results
are imprecise. We still show this in a hover badge, which is a much
nicer UI for this than a dismissible warning (which felt more "CYA").
- Remove command palette because it was inextricable from notifications
and it was only used by the Sourcegraph extension API (which is
deprecated and will be removed).
- Remove the old notifications UI, which showed notification messages in
Sourcegraph and code host UIs. This is no longer necessary with the
removal of the command palette, because it is no longer possible to
invoke long-running actions whose errors must be shown in a separate,
global UI.
## Test plan
Existing tests suffice to test the existing code intelligence
functionality. This PR just removes functionality.
We use the `neelance/parallel` package for two things right now:
1) a semaphore
2) a waitgroup/errgroup
It makes for a more-complex-than-necessary semaphore, and a non-standard
errgroup. We use it along with the `goroutine` package to log panics,
but most of the time, logging a panic is not really what we want. This
change was inspired by me getting confused by panics being swallowed in
tests.
This replaces uses of the package with a combination of
`sourcegraph/conc` and a new `internal/limiter`.
The new `internal/limiter` package is a very simple channel-based
semaphore, and I merged in the `internal/mutablelimiter` package so now
we have `limiter.New(n)` and `limiter.NewMutable(n)`.
`sourcegraph/conc` replaces the combination of `goroutine.Go()` and
`run.Acquire()`/`run.Release()` along with error collection and
cancellation in some cases. Additionally, it propagates panics rather
than just logging and ignoring them, which is often not good behavior.
* all: entirely remove minio support
IMPORTANT: Please note this change is NOT active for customers until the
CHANGELOG is updated and clearly states the removal of this for a specific
version of Sourcegraph.
This change entirely removes minio support from our codebase, in favor
of the new Apache-licensed `sourcegraph/blobstore` Docker image:
* All deployment types already no longer use minio, including:
* Single container `sourcegraph/server`
* Docker Compose
* Pure Docker
* Kubernetes deployment types (helm, kustomize, vanilla, etc.)
* AMI/image-based 'one click' deployments and script-install deployments
* Removed the Docker image so we no longer _distribute_ any minio code for
new Sourcegraph versions in the future.
* Removed the ability of Sourcegraph to even configure/use minio in any form.
* Updated third-party license information to reflect the change.
Helps #44254
Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>
* update license finder to 7.1.0
* use newer action for ruby
* add trim and root-workspace to ignore dependencies
* add updated license information
* update licenses from latest main
This has been deprecated for more than a year. We do not support self-service payment. See https://about.sourcegraph/pricing if you are a customer or want to be a customer.
The functionality remains for users to view license keys on Sourcegraph.com, and for us to generate license keys. There is no longer any way to see the billing history of subscriptions, but we have not supported the creation of such subscriptions for 2+ years. Any customers needing historical invoices may contact us.