dev,bazel: miscellaneous paper cuts

[irfansharif]

Describe the problem

Here's an assorted list of paper cuts we should address. They're grouped by size and should ease the transition away from make as a daily driver. Collecting them here for the Bazel CS team + volunteers.

Small:

• --rewrite should probably imply --ignore-cache
• list all supported build targets as part of 'dev build -h'
• stop munging ccache paths through dev to reduce build thrashing when switching between bazel/dev
• introduce a top-level --test-arg to pass arguments directly to the go test binary (see 'go help testflags' for all you can do); get rid of --rewrite-arg while here.
• when running test/benchmark with '-{cpu,mem}profile' passed to the underlying go test binary, it's not clear where the pprof output is placed
• support --stress{,-args}, --count for 'dev testlogic' (maybe unify the code paths with 'dev test'?)
• support --show-sql for 'dev testlogic'
• disable test sharding (--test_sharding_strategy=disabled) when --filter is specified; for sharded (like pkg/kv/kvserver) packages when filtering for a specific test, there's a lot of additional test runner output for spawns that don't do anything.
• symlink 'cockroach' to the 'cockroach-short' binary for 'dev build short'
• maybe stream 'dev test' output by default (i.e. use --test_output streamed instead), or provide a flag for it serializes test runs which may be undesirable
• bazel,dev: cannot rewrite from different package #76513
• dev test pkg/kv/kvserver -f TestNonExistent succeeds without any warnings; we could be peeking at the generated test.xml and spit out something:

$ cat _bazel/testlogs/pkg/kv/kvserver/kvserver_test/test.xml

• pprof profiles expects generated files to be found under bazel-out, but we stash them under _bazel/
  • Adding build --symlink_prefix=bazel- to .bazelrc.user is a temporary workaround. Alternatively commenting out build --symlink_prefix=_bazel/ in .bazelrc. See bazel: dev bench-created profile has insufficient source information #81748
  • To repro:

dev bench pkg/sql/colexec/colexecjoin -f=MergeJoiner/rows=32768 --count=5 --cpus=1 --test-args="-test.cpuprofile=cpu.out" --bench-mem
go tool pprof -http localhost:8081 cpu.out # navigate to "Source" view and see that listings for .eg.go files aren't resolvable

• pass '-no_warning_for_no_symbols' to libtool/ar on macs (gets rid of benign "has no symbols" warnings, hint)
• top-level dev clean (aliasing bazel clean {--expunge} and re-parenting dev ui clean --all to come underneath it
• dev gen bazel --short to only run gazelle

Medium:

• dev,bazel: check if the cache process is running #76527
• bazel: disable sandboxing for local development #79785
  • evaluate speedups if using a memory-mounted sandbox base; by-passing all IO.
• with vanilla go, when a test test hangs, you can ctrl-/ which a sigquit to Go and dumps all goroutines; with bazel the signal goes to bazelisk instead
• bazel: test scoped logs not directly available #74906
• bazel: investigate performance impact of nogo #73944
• dev: create an alias for buildtest #74457; add ability to build test targets without linking the test binaries (can noticeably slow things down)
• dev: generate go does not pull all generated files back into the repo #76276; add ability to hoist any and all generated code back into the workspace
• bazel: gomock bottlenecks build significantly #71854; don't generate gomock code through bazel
• bazel,dev: add ability to hoist generated protos without needing a full build #72233; add ability to hoist generated protos without needing a full build (you often want to protoc code gen to get your code to be compilable, say when changing a proto interface)
• provide an easy way to run a remote build cache locally, bazel's out-of-the-box cache busting is painful
• improve the testing story for dev (the mocks/recordings are being maintained by hand at the moment)

Epic CRDB-17171

Jira issue: CRDB-12679

[rickystewart]

I'm closing this. Most of the remaining paper cuts either already have GitHub issues set up, or they're tasks which I'm uncertain we'll actually implement.