Add an integration test for the test server

[josephschorr]

No description provided.

[jakedt]

let's use require.Eventually here too

[josephschorr]

ooo. Very cool

[jakedt]

add a check that a write against readonly fails

[josephschorr]

Updated

[jzelinskie]

can we standardize on a build tag? maybe replace this and ci with docker since that's what this requires

[josephschorr]

I'll change to docker, but leaving CI as is

[jzelinskie]

We maybe want to repurpose this whole job to be for e2e tests and eventually have evan's e2e tests run in here, too

[jzelinskie]

It'd be great if this could build the image, too so that devs can't accidentally run these tests with stale images.

[josephschorr]

I'd have to wire up the Docker API calls too; I think we should just move newTester into a util package, export it, and then optionally add a "build it not present" flag to it

[jzelinskie]

style nitpick that i think makes things more readable

_, err = rov0client.Write(context.Background(), &v0.WriteRequest{
	Updates: []*v0.RelationTupleUpdate{{  // <---- 
		Operation: v0.RelationTupleUpdate_CREATE,
		Tuple: &v0.RelationTuple{
			ObjectAndRelation: &v0.ObjectAndRelation{
				Namespace: "resource",
				ObjectId:  "someresource",
				Relation:  "reader",
			},
			User: &v0.User{UserOneof: &v0.User_Userset{Userset: &v0.ObjectAndRelation{
				Namespace: "user",
				ObjectId:  "somegal",
				Relation:  "...",
			}}},
		},
	}},
})

[josephschorr]

I actually disagree; I'd wonder how I'm adding a single item directly to the slice

[jzelinskie]

well, this is how it's done in many places in the codebase, so we should pick one

[jzelinskie]

can't we declare a variable for this tuple? we're reusing it here
that'd even let us use tuple.ToRelationship in the other test

[jzelinskie]

I really don't like this function name or design even as we've used it in the other tests.

It doesn't have the container details in it, but it does have the knowledge that the container will somehow be SpiceDB because of the healthcheck built into it.

Now that we've copied and pasted this code a few places, can we make it more generic?

[josephschorr]

Personally, I want it into a util package that SpiceDB exports

[ecordell]

What about moving this into the e2e package from #75? the test would build/run much faster, and avoid the need for build tags (plus that e2e GHA already handles caching).

[josephschorr]

I explicitly want this tested against the built binary image, as that's how people are going to be using it most of the time. Unless I'm mistaken, #75 doesn't run the server as a distinct binary?

[ecordell]

It does, it execs the built spicedb

[josephschorr]

Updated, but still using Docker. Will issue a followup commit to change to use the e2e stuff once in

I'd rather this go in now and get cleaned up later than have the branch stagnate.