Allow TCK to run as docker container

[pvlugter]

For #216. Some minimal changes on the TCK so that it can be run independently, using docker, to be part of language support builds.

The parts of the TCK tests that manage processes have been moved under the integration testing. These should still work and run the same as before.

Package the base TCK as a docker image. Publish locally with:

sbt tck/Docker/publishLocal

Example of running all from docker, with port binding and using host.docker.internal:

docker run -d --name cloudstate-function -p 8080:8080 cloudstateio/samples-js-shopping-cart
docker run -d --name cloudstate-proxy -p 9000:9000 -e USER_FUNCTION_HOST=host.docker.internal -e USER_FUNCTION_PORT=8090 cloudstateio/cloudstate-proxy-dev-mode

# can check exit status; this will fail if the TCK fails:
docker run --rm --name cloudstate-tck -p 8090:8090 -e TCK_HOST=0.0.0.0 -e TCK_PROXY_HOST=host.docker.internal -e TCK_FRONTEND_HOST=host.docker.internal cloudstateio/cloudstate-tck

docker rm -f cloudstate-proxy
docker rm -f cloudstate-function

Or using host network to simplify port binding:

#!/usr/bin/env bash

set -x

docker run -d --name cloudstate-function --net=host cloudstateio/samples-js-shopping-cart
docker run -d --name cloudstate-proxy --net=host -e USER_FUNCTION_PORT=8090 cloudstateio/cloudstate-proxy-dev-mode

docker run --rm --name cloudstate-tck --net=host cloudstateio/cloudstate-tck
status=$?

docker rm -f cloudstate-proxy
docker rm -f cloudstate-function

exit $status

Example run:

+ docker run -d --name cloudstate-function --net=host cloudstateio/samples-js-shopping-cart
1100467cdc557a2f58d7c7cc04126e7e87840e63f9427d16b3315e7473b9a4a9
+ docker run -d --name cloudstate-proxy --net=host -e USER_FUNCTION_PORT=8090 cloudstateio/cloudstate-proxy-dev-mode
26dd5270affcc8da22df95b48a09a0e19a1cb0403f3494f3442a480fe0b6062c
+ docker run --rm --name cloudstate-tck --net=host cloudstateio/cloudstate-tck
Run starting. Expected test count is: 5
ConfiguredCloudStateTCK:
Cloudstate TCK
- must verify that the user function process responds
- must verify that an initial GetShoppingCart request succeeds
- must verify that items can be added to, and removed from, a shopping cart
- must verify that the backend supports the ServerReflection API
- must verify that the HTTP API of ShoppingCart protocol works
Run completed in 8 seconds, 730 milliseconds.
Total number of tests run: 5
Suites: completed 1, aborted 0
Tests: succeeded 5, failed 0, canceled 0, ignored 0, pending 0
All tests passed.
+ status=0
+ docker rm -f cloudstate-proxy
cloudstate-proxy
+ docker rm -f cloudstate-function
cloudstate-function
+ exit 0

[pvlugter]

@marcellanz @sleipnir could you try out the docker image locally, to see how it will be to use this in language support builds?

[viktorklang]

@srikanthops @jroper You'll probably want to have a look at this

[marcellanz]

@pvlugter very nice!
I tested the branch locally and it ran the TCK against the Go language support as expected. 👍

[sleipnir]

Hi @pvlugter awesome work!
I ran it locally with Dart and it worked as expected. I test with the host network.
Thanks!

# ./tck.sh 
+ docker run -d --name cloudstate-function --net=host sleipnir/cloudstate-dart-shoppingcart:0.5.5
docker: Error response from daemon: Conflict. The container name "/cloudstate-function" is already in use by container "c4df6d33aa0896b198c78998e3cfc0a8803df81824fbe8b75ab425c16050b387". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
+ docker run -d --name cloudstate-proxy --net=host -e USER_FUNCTION_PORT=8090 cloudstateio/cloudstate-proxy-dev-mode
8efcfa635bbc184219fa58256c9f5e86767ba990628ea08c6227b17f6a654315
+ docker run --rm --name cloudstate-tck --net=host cloudstateio/cloudstate-tck
Run starting. Expected test count is: 5
ConfiguredCloudStateTCK:
Cloudstate TCK 
- must verify that the user function process responds
- must verify that an initial GetShoppingCart request succeeds
- must verify that items can be added to, and removed from, a shopping cart
- must verify that the backend supports the ServerReflection API
- must verify that the HTTP API of ShoppingCart protocol works
[ERROR] [05/19/2020 15:04:04.010] [CloudStateTCK-akka.actor.default-dispatcher-8] [akka://CloudStateTCK/system/pool-master] connection pool for Pool(shared->http://127.0.0.1:9000) has shut down unexpectedly
java.lang.IllegalStateException: Pool shutdown unexpectedly
	at akka.http.impl.engine.client.PoolInterface$Logic.postStop(PoolInterface.scala:214)
	at akka.stream.impl.fusing.GraphInterpreter.finalizeStage(GraphInterpreter.scala:599)
	at akka.stream.impl.fusing.GraphInterpreter.finish(GraphInterpreter.scala:324)
	at akka.stream.impl.fusing.GraphInterpreterShell.tryAbort(ActorGraphInterpreter.scala:664)
	at akka.stream.impl.fusing.ActorGraphInterpreter.$anonfun$postStop$1(ActorGraphInterpreter.scala:802)
	at akka.stream.impl.fusing.ActorGraphInterpreter.$anonfun$postStop$1$adapted(ActorGraphInterpreter.scala:802)
	at scala.collection.immutable.Set$Set2.foreach(Set.scala:159)
	at akka.stream.impl.fusing.ActorGraphInterpreter.postStop(ActorGraphInterpreter.scala:802)
	at akka.actor.Actor.aroundPostStop(Actor.scala:554)
	at akka.actor.Actor.aroundPostStop$(Actor.scala:554)
	at akka.stream.impl.fusing.ActorGraphInterpreter.aroundPostStop(ActorGraphInterpreter.scala:691)
	at akka.actor.dungeon.FaultHandling.finishTerminate(FaultHandling.scala:215)
	at akka.actor.dungeon.FaultHandling.terminate(FaultHandling.scala:173)
	at akka.actor.dungeon.FaultHandling.terminate$(FaultHandling.scala:143)
	at akka.actor.ActorCell.terminate(ActorCell.scala:410)
	at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:517)
	at akka.actor.ActorCell.systemInvoke(ActorCell.scala:533)
	at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:295)
	at akka.dispatch.Mailbox.run(Mailbox.scala:230)
	at akka.dispatch.Mailbox.exec(Mailbox.scala:243)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

Run completed in 7 seconds, 905 milliseconds.
Total number of tests run: 5
Suites: completed 1, aborted 0
Tests: succeeded 5, failed 0, canceled 0, ignored 0, pending 0
All tests passed.
+ status=0
+ docker rm -f cloudstate-proxy
cloudstate-proxy
+ docker rm -f cloudstate-function
cloudstate-function
+ exit 0

[sleipnir]

@pvlugter @viktorklang @marcellanz Now to be perfect I thing we only have to make this image of the tck available on Dockerhub, so we don't need sbt to publish the local image and anyone can run the tck directly from the Dockerhub image

[viktorklang]

Publishing a Cloudstate release should include pushing the TCK Docker image to Dockerhub. And we should probably push a nightly or similar as ”latest”. Thoughts? -- Cheers, √

[marcellanz]

I welcome a nightly build. If needed I would build locally a new tck image, but having a nightly build would help to just run the tck without beeing in the loop of potential current development where one needs something like node/npm on the correct version.

Currently the main cloudstate repository runs the TCK against all language support implementations supported and we get a quick feedback about the health of the proxy in combination with all language support libraries. When the support libraries runs the TCK by their own, we loose this information. So, do we like to somehow re-establish that?

[sleipnir]

@viktorklang I agree
@marcellanz could we use github tags to support this? Just as some projects use travis tags to indicate the health of the repository, we could use tags to indicate whether support language builds pass and more specifically a tag for tck for each support language.
Would it be very difficult to achieve this kind of thing?

[marcellanz]

@sleipnir that would be for master-master combinations, right?
A language support lib would probably not release a new version if it fails against latest proxy released. But a support library could fail temporarily against latest released proxy or even proxies master:

lib-master : proxy-master
lib-master : proxy-vX.Y.Z

and vice-versa. Is this needed? How would we tag this? It seems that needs tag for every nightly build?

(I'm just asking because I don'tunderstand yet how that works yet, not because I think it would not work.)

[sleipnir]

@marcellanz is just an idea, but I have no idea if it is feasible, we would have to include it in the travis pipeline or a customized github workflow

[marcellanz]

👍 I like the idea a lot, having the build status reported to the main repository.
Perhaps I got it wrong, with the tag is it like the build badges travis has?
https://docs.travis-ci.com/user/status-images/

this way I could imagine having a branch or master built and tested against the TCK and if that fails, the badge gets red or the like and this can be used by the main project to track the support libraries health.

[sleipnir]

this this this this :D
I said tag wrongly, I wanted to say just like the status of travis

[pvlugter]

I've added the TCK docker publish to the travis build. That should be all we need to get release and latest snapshot images published.

[viktorklang]

Nice work, @pvlugter!

[viktorklang]

Excellent work, @pvlugter!

[viktorklang]

@pvlugter @srikanthops @edwardcallahan Can you check what needs to be done in order to make sure that CircleCI works with this?

[pvlugter]

The CircleCI native-image integration tests should work same as before (not that they're currently running here). I've pushed this branch to lightbend/cloudstate-ci for the CircleCI build, and it passes there:

https://circleci.com/gh/lightbend/cloudstate-ci/74

So this should be good to go. I'll merge and tag, so that there are versioned docker images to start using.

[pvlugter]

I've tagged v0.5.1 and the travis build has published docker images. So the following images can be used for running TCK in language supports:

cloudstateio/cloudstate-proxy-dev-mode:0.5.1
cloudstateio/cloudstate-tck:0.5.1

Note that the travis build will also publish for any pushes to master under the latest tag.

I've also manually published native image build for proxy dev mode:

cloudstateio/cloudstate-proxy-native-dev-mode:0.5.1

which can also be used when running the TCK.

[marcellanz]

@pvlugter nice 👍
I integrate that into the Go support.

[marcellanz]

@pvlugter I use these docker images now to verify the Go implementation against the TCK in various combinations like:

• go-tck:latest vs. proxy:latest
• go-tck:latest vs. proxy:0.5.1
• go-tck:latest vs. proxy-native:0.5.1
• go-tck:0.1.0 vs. proxy:latest
• go-tck:0.1.0 vs. proxy-native:latest

I have not yet found a good way to visualize this matrix on a projects README.md or the like.

https://travis-ci.com/github/marcellanz/go-support:

WIP branch for this:
https://github.com/marcellanz/go-support/tree/feature/crdt_support