go test ./... fails with -cockroach-binary flag about cockroach-go HOT 7 CLOSED

Hey. Any update on this?

from cockroach-go.

I agree that the -cockroach-binary is pretty useless. I also think that the default binary used by the test server is useless - it defaults to a nightly build, right?
Passing the version to the test server constructor sounds right to me. I'd use the option pattern to do it. Additionally, I think an env var that overrides specified binary version option would also be a good idea.

Generally, I do wonder about the future of the testserver library, though. An alternative to the current model of spinning up a separate cockroach server process is to run cockroach in the test's (Go) process. That's how most of the test for crdb itself run - they start servers in-process, and those server use in-memory stores (an external process could also use the in-memory store if we configured it accordingly). A problem with this is that the client test would have to vendor the whole cockroach codebase, and more importantly it'd need to be able to build crdb. The build process currently is pretty involved with a bunch of dependencies, but I think we could simplify it for these test purposes. I am curious to get your opinion on in-process vs out-of-process crdb.

from cockroach-go.

I meant passing local path to the binary, as its done via the -cockroach-binary flag right now. But just version also works.

Here is the download link: https://edge-binaries.cockroachdb.com/cockroach/cockroach.darwin-amd64.LATEST
I can't tell is it a nightly build or not, actually.

it defaults to a nightly build, right?

As an application developer I want a simple interface to start a test crdb server. testserver package does it pretty well (but it lacks some customisation options). If it possible to start a crdb server in test's Go process as simple as:

testserver.StartTestServer("19.6" /* version */)

With all building and other stuff hidden inside, it could be a replacement to the current implementation.
But I guest it will be hard to build a specific cockroachdb version in vendor codebase.
And even if do possible to achieve that, I don't actually see any benefits compared to the current out-of-process crdb, if we enrich testserver package with customization (see also #69)

from cockroach-go.

Any updates?

from cockroach-go.

I would be open to a PR that changes testserver to use an environment variable for the file path if it's specified. That seems like the most lightweight change.

The idea of passing in a version number into NewTestServer is also pretty appealing. It will be a slightly harder lift since you'll have to refactor testserver/binaries.go to make it aware of different version number URLs. But if you keep the interface backwards compatible (I agree the options pattern sounds good), then feel free to give this a shot too.

FYI: all the published versions have predictable URLs that will never change. You can see them all here: https://www.cockroachlabs.com/docs/releases/

from cockroach-go.

I would go with an environment variable for the binary path because this will allow running tests offline after you have the cockroach binary installed locally.

from cockroach-go.

For what it's worth, I was able to figure out how to use the -cockroach-binary flag for tests. The command is like this:

go test -p 1 -race -v ./... -args -cockroach-binary=/path/to/cockroach

from cockroach-go.