The previous approach to enable race detection was too radical and
accidently led to build our binaries with the race flage enabled, which
caused issues when building images down the line.
This happened because putting a `test --something` in bazelrc also sets
it on `build` which is absolutely not what we wanted. Usually folks get
this one working by having a `--stamp` config setting that fixes this
when releasing binaries, which we don't at this stage, as we're still
learning Bazel.
Luckily, this was caught swiftly. The current approach insteads takes a
more granular approach, which makes the `go_test` rule uses our own
variant, which injects the `race = "on"` attribute, but only on
`go_test`.
## Test plan
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
CI, being a main-dry-run, this will cover the container building jobs,
which were the ones failing.
---------
Co-authored-by: Alex Ostrikov <alex.ostrikov@sourcegraph.com>
If the next function returns a non-empty slice and a non-nil error we
still iterate over the returned items before stopping the iteration.
Previously iteration stopped as soon as a non-nil error was returned.
Test Plan: go test
In a few places we have different patterns around pagination:
- Passing a closure in
- Returning a cursor for the client to use
- Just collect everything into a big slice
Other go libraries often will setup pagination patterns / use
interfaces. The API I quite like is the stripe-go one which is minimal
and reminds me a lot of Scanner from the stdlib. You just do something
like
for it.Next() {
doSomething(it.Current())
}
if it.Err() != nil {
handle
}
I imagine if we had this interface a few useful methods like
Map[A,B](func(A() B, Iterator[A]) Iterator[B]
Collect(Iterator[T]) ([]T, error)
etc. Basically could implement the same functions as present in
https://pkg.go.dev/golang.org/x/exp/slices
