Tests are failing when running on M1 Mac

[onobc]

Steps to reproduce: Run gradle clean build on an M1 Mac.

Possible cause: Pulsar image running super slow because of M1 Mac?

Workaround: Modify the image used in https://github.com/spring-projects-experimental/spring-pulsar/blob/749f2dbb5e386f77e842af2ece547fbdc0e8f84f/spring-pulsar/src/test/java/org/springframework/pulsar/core/AbstractContainerBaseTests.java#L24
with

static final DockerImageName PULSAR_IMAGE = DockerImageName.parse("kezhenxu94/pulsar").asCompatibleSubstituteFor("apachepulsar/pulsar");

Work items

1. Understand what the root cause is. What is in the alternative image that makes it work? Is there some other change we should be considering or is this just the "M1 support in general is still catching up" category?
2. Temporary stop-gap so that other users do not run into this, we could implement the above workaround automatically via Junit5 @EnabledOnOs annotation (one for M1 and one for all others).

[alpreu]

I believe the root cause is that the standard Pulsar image running through emulation is very slow. This leads to Testcontainers startup check to time out, thus stopping further test execution.

The issue around offering ARM based images can be found here:
apache/pulsar#12944

And the experimental image above was built using this PR:
apache/pulsar#14005

I tried to re-ignite the discussion on the mailing list around this topic and looped in colleagues as well.

For the time being, I think it's a good idea to enable the workaround using the JUnit annotation as you described above.

Edit: After some further investigation this is not as straightforward. The JUnit annotation only works on a (@test) method level, not block-level. So we cannot keep the shared testcontainer as it is. The second problem is that the architecture. parameter of the annotation internally uses System.getProperty("os.arch"). Because this is depending on the JDK, and not implemented on the actual system level, this can return x86_64 even for M1 macs (see https://stackoverflow.com/questions/69497067/java-sdk-reporting-wrong-architecture-on-mac-m1).

Maybe the best way is to let users set an environment variable if they are using the M1 chip and exchange the image name when it's set.

[onobc]

Great find @alpreu - thanks for digging in.

Maybe we can put a custom "condition" in the static initializer to determine image name.

	static {
		MyCustomCondition isMacCondition = ...
		if (isMacCondition) {
			image = "";
		}
		else {
			image = "";
		}
		DockerImageName PULSAR_IMAGE = DockerImageName.parse("apachepulsar/pulsar:2.10.1");
		PULSAR_CONTAINER = new PulsarContainer(PULSAR_IMAGE);
		PULSAR_CONTAINER.start();
	}

We would still need to find the "magic formula" from inspecting system props to determine if it is M1. However, based on t he info in previous comment it may not be a solid approach w/ sys props as it only reports to the jvm. Let's explore any other means to determine if the current user is on an M1 or not. We could always drop back to the ENVVAR idea as well.

[onobc]

NOTE: As of 2.11.0 the standard Pulsar image is now able to run on Mac M1.