This runs playwright tests with bazel. This changes how the
app is served in the tests, specifically playwright will intercept all
network calls to the local server and serve the static assets directly
or serve root index.html file if nothing is matched.
---------
Co-authored-by: bahrmichael <michael.bahr@sourcegraph.com>
Co-authored-by: Jean-Hadrien Chabran <jh@chabran.fr>
Co-authored-by: Michael Bahr <1830132+bahrmichael@users.noreply.github.com>
Co-authored-by: Jean-Hadrien Chabran <jean-hadrien.chabran@sourcegraph.com>
Co-authored-by: Camden Cheek <camden@ccheek.com>
Currently, we provide single-file tools such as `ctags`, `gsutil` etc via an `sh_binary` wrapper, to have a single target to reference that automatically does platform selection of the underlying tool.
Due to some [unfortunate reason](https://github.com/bazelbuild/bazel/issues/11820), the underlying srcs (which is [a single file](https://bazel.build/reference/be/shell#sh_binary.srcs)) of an `sh_binary` are also exposed as outputs (rather than just as typical runfiles) alongside the script that wraps. This is _sometimes_ problematic when doing location expansion (e.g. `$(location ...)`) due to these only allowing a single output (dont ask why this works in some contexts but not others, I dont know).
To address this, we create a wrapper macro + rule to replicate what we want from `sh_binary` (automatic platform selection + tool naming), while only exposing a singular file.
See example of currently required approach to consuming a tool: [BUILD.bazel](https://github.com/sourcegraph/sourcegraph/pull/62801/files#diff-e2a562c2e13908933b2ee24f0ac596829b38a5325cc69a4aee05c383aaa2e494R8) & [main_test.go](https://github.com/sourcegraph/sourcegraph/pull/62801/files#diff-7a91cb5143064bfc8993ef97baf68b718ef49747ccc1d3c5e1150d4696b88305R66).
With this change, `rlocationpath` (singular) can be used instead (or any of the other singular nouns in different contexts), as well as no `strings.Split/strings.Fields` being required
## Test plan
`bazel cquery --output=files //dev/tools:dropdb` yields 1 vs 2 files.
Also updated the rule behind `//internal/database:generate_schemas` due to the workaround in it for the fact that the underlying srcs was also exposed. The correctness is verified by running said target (locally + CI)
* appliance: golden/snapshot testing
Use envtest (https://book.kubebuilder.io/reference/envtest.html) to
start a real Kubernetes API server, backed by a real etcd instance, in
tests. The only controller running is our appliance controller, so these
tests assert on the changes our controller actually makes to Kubernetes
API objects in response to some input, but don't depend on complex
infrastruture like container runtimes or persistent volume controllers
(since no such controllers are actually running, unlike in a useful
Kubernetes cluster).
This commit adds a test harness to the appliance package:
* It starts the k8s API server only once, not once per test, as this is
a relatively slow operation.
* Helper functions to run each test in a unique namespace to avoid
inter-test dependency. This opens the door to parallelism, but note
that testify/suite doesn't currently support parallel tests.
* Helper functions to load input ConfigMaps from fixture files.
* Passing `-args appliance-update-golden-files` to `go test` will cause
checked-in golden files to be updated.
Use nix to compile and upload universal-ctags to a gcloud bucket. We then pull this down using a bazel http_file and can run it with bazel also. Removed all of the old bash logic that was hard to follow and maintain also.
---------
Co-authored-by: Noah Santschi-Cooney <noah@santschi-cooney.ch>
Co-authored-by: William Bezuidenhout <william.bezuidenhout@sourcegraph.com>
This PR is on top of #54517
---
This PR rework how we handle the docsite and some of its related tasks:
- While we _could_ avoid committing the generated files to disk, the way
that docsite currently works, requires to have all files available in
git, so the docsite can serve various versions.
- `bazel run //doc/cli/references:write_doc_files` handles this (and
it's umbreall `//dev:write_all_generated`.
- Its generation is now handled by `//doc/cli/references:generate_doc`
and its associated test.
- `sg run docsite` now calls `bazel run //doc:serve`, we don't need to
install the docsite directly anymore (but it's available under `bazel
run //dev/tools:docsite` if needed).
As a byproduct, we can now run `src-cli` with `bazel run
//dev/tools:src-cli` which will pick the correct binary for your machine
transparently.
## Test plan
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
Locally tested + CI
Shaves about 30/40s from `sg lint` where docs are detected as well as
all builds on `main`, as doc changes are pretty rare, and we're
unecessarily testing those in every commit reaching `main`.
## Test plan
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
Locally tested + CI
