Disable Oracle db tests on Mac M1 because of segfault (and updated readiness check)

[holly-cummins]

Partial resolution of #25428. See also discussion in #25648.

To test,

TESTCONTAINERS_RYUK_DISABLED="true" ./mvnw -Dquickly -DskipTests=false -Dstart-containers -f integration-tests/reactive-oracle-client/pom.xml
TESTCONTAINERS_RYUK_DISABLED="true" ./mvnw -Dquickly -DskipTests=false -Dstart-containers -f integration-tests/jpa-oracle/pom.xml
TESTCONTAINERS_RYUK_DISABLED="true" ./mvnw -Dquickly -DskipTests=false -Dstart-containers -f extensions/reactive-oracle-client/deployment/pom.xml

(this is now a no-op on M1 but it should be more interesting on other architectures, because I've swapped one of the log-search-based startup checks with a health check).

What's changed?

I hit fabric8io/docker-maven-plugin#1369 with the log readiness check. Based on the discussion, I wonder if it’s a timing issue which my machine exposes by being fast. (I saw similar issues with <log> experimenting with the mariadb readiness check.)

ERRO[20873] accept tcp [::]:1521: use of closed network connection
[ERROR] DOCKER> IO Error while requesting logs: org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected Thread-6

The image we use has a healthcheck configured, so we can just use that with fabric8 docker-maven-plugin.

I also hit a more serious problem, which is that I could not get the database to start on M1. It seemed to be the same issue as https://stackoverflow.com/questions/68605011/oracle-12c-docker-setup-on-apple-m1. Others there reported success with qemu, which podman is using under the covers. I tried with podman 4.0.3 and podman 4.1, without success.

Reluctantly, I disabled the tests. We should re-evaluate with later versions of the Oracle database in the future.

[holly-cummins]

That was a total cut and paste fail, thanks @gastaldi! I've fixed (including the comment) and squashed. What's interesting is that it didn't actually make a difference. I'd thought in the override of the docker-maven-plugin configuration I had to specify an image to skip, but I guess changes to the docker-maven-plugin <images> collection are applied at the level of overwriting the whole collection, rather than individual <image> definitions within it.

[gastaldi]

@holly-cummins my guess is that if you set <skip>true</skip>, the rest of the config may be set but it doesn't matter because it's never run

[holly-cummins]

@holly-cummins my guess is that if you set <skip>true</skip>, the rest of the config may be set but it doesn't matter because it's never run

I think that must be right, @gastaldi. I'd assumed <images> would be a bit like <properties>. If you had

<properties>
   <foo>a</foo>
   <bar>b</bar>
</properties> 
<profile>
   <properties>
     <foo>f</foo>
     <baz>d</baz>
  </properties>
</profile>

The final configuration would be

<properties>
   <foo>f</foo>
   <bar>b</bar>
   <baz>d</baz>
 </properties>

I assumed the <images> would work in a similar way and if you defined an <image> in a profile it would be an addition, not an override. So you'd end up with two <image> children unless the names matched exactly. And one of <image>-children would be skipped, and one wouldn't, which would be Unfortunate. But I guess matching and overriding basing on a name-child is kind of complex and it doesn't do that.

In which case, I could perhaps remove the <name> element from the <image> override altogether. I guess the reason not to is for clarity of what's being skipped (when I haven't put in the wrong name, that is!).

[gastaldi]

Suggested change

	<!-- leversge the healthcheck in the image we use -->
	<!-- leverage the health check in the image we use -->

[gastaldi]

Oh shoot, forgot to apply the typo fix, anyway, let's move on and fix that as part of another PR