Allow starting Pub/Sub emulator for local development and integration testing

[breun]

Spring Cloud GCP's support for Datastore starts the Datastore emulator when spring.cloud.gcp.datastore.emulator.enabled is set to true, which is very convenient for local development and integration testing.

Could Spring Cloud GCP's support for Pub/Sub add a similar configuration property that starts up a Pub/Sub emulator instead of requiring an emulator to be started via some other way when setting spring.cloud.gcp.pubsub.emulator-host?

[meltsufin]

I believe it's possible in principle. We started a refactoring of our emulator support across the board here, but it has been put on hold for now.

In the meantime, we'd be open to a small change targeted at the Pub/Sub emulator support for the auto-start, if someone is willing to make a contribution.

Also, have you considered using test-containers for Pub/Sub emulator? See: https://www.testcontainers.org/modules/gcloud/

[breun]

Using Testcontainers is not an option at our company. You need Docker-in-Docker for Testcontainers and we don’t have that enabled on our CI, because that poses a security risk.

[bsideup]

@breun have you considered using the Rootless Docker? It runs under your current user, does not require root access to the host machine, while providing the same Docker experience as you would get with "classic" Docker :)

[breun]

@bsideup I didn't know about Rootless Docker. Do you know of any resources on how to make that work on GitLab CI? Would this require any specific GitLab setup from our CI team? I found this open story for GitLab CI for rootless Docker support and my first impression is that that is not yet supported: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4712

Currently our teams use a hybrid setup with a profile for docker-maven-plugin to start the Pub/Sub emulator locally and a GitLab service when running on GitLab CI. This could be simplified greatly with the equivalent of spring.cloud.gcp.datastore.emulator.enabled for Pub/Sub.

I'd also be happy to learn about a way to use Testcontainers on GitLab CI without Docker-in-Docker enabled, because that would indeed make even more local/testing scenarios simpler.

[bsideup]

@breun I guess it is better to ask in Gitlab's community on how to use the Rootless Docker mode with their solution. The "rootless" part lifts a lot of restrictions so it shouldn't differ much from running any other Linux process.

P.S. consider reaching out to Team Axle who got contacted about Testcontainers at Bol ;) You can also hit me up on Twitter / Testcontainers' Slack :)

@meltsufin sorry for hijacking the conversation btw :)

[breun]

@bsideup I'm in that team. :) But we're the JVM application framework team, not the CI team, so this is not my area of expertise. But I'll poke our CI team about Rootless Docker, GitLab CI and Testcontainers.

[elefeint]

Internally in the project, we have a PubSubEmulator JUnit rule that starts/stops the emulator automatically. Would this be useful? We could move the rule into a reusable spring-cloud-gcp-test-support project.

Here is example usage from PubSubMessageChannelBinderEmulatorIntegrationTests:

@ClassRule
public static PubSubEmulator emulator = new PubSubEmulator();

[breun]

@elefeint That looks interesting to make public for users indeed, but @Rule and @ClassRule were removed in JUnit 5, so this would only work for JUnit 4 projects. JUnit 5 replaced @Rule and @ClassRule with the new @ExtendWith mechanism, so it would be nice to also provide a solution for JUnit 5 users. (We're using JUnit 5 for our projects ourselves.)

And it might be good to provide some consistency across Spring Cloud GCP on how to use the emulators.

[meltsufin]

I think the best way forward would be to try to contribute something to the Pub/Sub client library based on https://github.com/googleapis/java-datastore/blob/master/google-cloud-datastore/src/main/java/com/google/cloud/datastore/testing/LocalDatastoreHelper.java and then use it in Spring Cloud GCP.

[lucasoares]

Hello guys.

@breun I will share my approach using Gitlab CI and to be honest I do like it more now than using emulators in-code:

services:
  - name: storytel/gcp-pubsub-emulator
    command: ["start", "--host=0.0.0.0", "--port=8082"]

You can use this on an individual job or just set this in the global configuration.
You can also create your own image to have more control over how this image is generated.

Why I like this approach:

• Our code is lighter and doesn't have additional code to run infrastructure.
• The build CI image does not need a gcloud SDK configured.
• We have a docker-compose file so developers can easily run those images (databases and tools like PubSub) locally just by running docker-compose up pubsub.

I don't know if this is an available option for you but with this approach, you can have all your databases and tools used in integration servers running with the same pattern. If you chose to depend on each individual technology you use, this will be difficult to maintain and to change technology in the future.

For now, as @meltsufin mentioned, we still have to wait for a LocalPubSubHelper from googleapis.

[breun]

@lucasoares Currently we also use that approach, but we don't really like it, because this way dependencies need to be configured twice: once for tests running on GitLab CI and once for local development and integration testing using docker-maven-plugin/docker-compose. We'd prefer one way to works for any scenario, like the configuration properties or some kind of JUnit support.

[meltsufin]

Since the proposal to add LocalPubSubHelper to the Pub/Sub client library was rejected, we can proceed with adding it to this project instead.

[emmileaf]

Closing as unplanned given age and priority of this feature request.