4e31a4e38d
Currently, all backend integration tests transitively depend on the client bundle. This results in rebuilds of the closure, and a (likely) cache miss on the test, when modifying any client-side files.
Given that the client bundle isnt needed for these tests, we can create targets that don't include the client bundle in its transitive closure, which should in theory improve the cache hit for backend integration tests by not having client side changes invalidate it. This would also be beneficial in local env, to keep frontend rebuilds down
To do this, we still need to create a `web.manifest.json` file due to some unfortunate requirement on that file existing as part of initializing the sourcegraph instance. For this I just create an empty json file, `select` this instead of the client bundle target in client/web/dist/BUILD.bazel based on a `//:integration_testing_enabled` config setting, and creating a `go_binary`-wrapping bazel rule + macro that automatically applies a transition to set this to true `go_binary_nobundle`, and using that rule for the specific `//cmd/{server,frontend}:{server,frontend}_nobundle` binary rules (along with the relevant `oci_{image,tarball}` etc rules to consume it).
## Test plan
- Integration tests in CI still work
- `bazel cquery 'kind("js_library", deps(//cmd/frontend:image_nobundle))'`, `bazel cquery 'kind("js_library", deps(//cmd/server:image_nobundle))'`, ``bazel cquery 'kind("js_library", deps(//testing:backend_integration_test))'` etc all return empty set
- Release test with marker in web bundle to ensure released images contain the web bundle via `sg release run test --version 5.4.2` (commenting out other tests for brevity)
|
||
|---|---|---|
| .. | ||
| __mocks__ | ||
| bookmarklet | ||
| dev | ||
| dist | ||
| src | ||
| .bazelignore | ||
| .eslintignore | ||
| .stylelintrc.json | ||
| BUILD.bazel | ||
| bundlesize.config.js | ||
| package.json | ||
| README.md | ||
| statoscope | ||
| tsconfig.json | ||
| vitest.config.ts | ||
Web Application
Local development
Use sg CLI tool to configure and start local development server. For more information check out the sg documentation.
Our local development server runs by starting both a Caddy HTTPS server and a Node HTTP server. We then can reverse proxy requests to the Node server to serve client assets under HTTPS.
Configuration
Environment variables important for the web server:
WEB_BUILDER_SERVE_INDEXshould be set totrueto enable serving of an index page.SOURCEGRAPH_API_URLis used as a proxied API url. By default it points to the https://k8s.sgdev.org.
It's possible to overwrite these variables by creating sg.config.overwrite.yaml in the root folder and adjusting the env section of the relevant command.
Development server
sg start web-standalone
Public API
To use a public API that doesn't require authentication for most of the functionality:
SOURCEGRAPH_API_URL=https://sourcegraph.com sg start web-standalone
Production server
sg start web-standalone-prod
Web app should be available at https://${SOURCEGRAPH_HTTPS_DOMAIN}:${SOURCEGRAPH_HTTPS_PORT}. Build artifacts will be served from <rootRepoPath>/client/web/dist.
Note: If you are unable to use the above commands (e.g. you can't install Caddy), you can use sg run web-standalone-http instead. This will start a development server using only Node, and will be available at http://localhost:${SOURCEGRAPH_HTTP_PORT}.
API proxy
In both environments, server proxies API requests to SOURCEGRAPH_API_URL provided as the .env variable.