Simplify container testing

[gsmet]

This is a follow-up from a discussion we had months ago. Names were suggested by @stuartwdouglas and I think they make sense.

It's a bit longer to type but at least you don't have to check in the pom if it should be test-pgsql or test-postgresql/test-mariadb or test-mysql and everything is consistent.

Use:
-Dtest-containers to enable container testing rather than all variants
of -Dtest-postgresql, -Dtest-mariadb and so on
-Dstart-containers to start the containers rather than -Ddocker

I also make the native builds consistently use containers.

Let's see what CI has to say.

/cc @zakkak

[stuartwdouglas]

Very much +1 on this, the current state of affairs is a bit of a mess.

[gsmet]

@loicmathieu I had to keep the logging-gelf extension special cased as it doesn't automatically start the containers.

That means that right now, this extension is not tested at all on CI, which is unfortunate. Any chance we could improve this situation?

[loicmathieu]

@gsmet there is already an issue for that, #6286 and it's assigned ... to you ;)

Someone definilty needs to work on making the logging-gelf IT works in CI.
If wa can use testcontainers in CI (it was not the case when the logging-gelf extension was created due to issue on windows build), it should be doable

[zakkak]

Thanks for the notification @gsmet !
+1 on this

Could you please also explain why -Dstart-containers does not imply -Dtest-containers?
I can see how one could use -Dtest-containers and manage the containers manually, but it's not clear to me why one would want to use -Dstart-containers without -Dtest-containers.

[gsmet]

@zakkak unfortunately, it's not easy to do that with standard Maven profiles. At least that's my understanding of it.

[gsmet]

Hmm, I wonder if just setting the property test-containers in the start-containers would be enough to trigger things. I would have to check that.

I was thinking about the lack of flexibility of <activation> but using properties might work.

I'll go try that and report back.

[gsmet]

AFAICS, it's not working.

[zakkak]

Hmm, I wonder if just setting the property test-containers in the start-containers would be enough to trigger things. I would have to check that.

I think adding something like:

<profile>
            <id>start-containers</id>
            <activation>
                <property>
                    <name>start-containers</name>
                </property>
            </activation>
            <properties>
                <start-containers>true</start-containers>
                <test-containers>true</test-containers>
            </properties>
</profile>

in integration-tests/pom.xml and extensions/pom.xml or directly in the top level pom.xml would achieve what we want.

My maven-fu is not that good though so I can't be sure without testing.

[gsmet]

I tried to do something similar but in a specific IT and it didn't work. Not sure if doing it in the parent would change something.

[zakkak]

I tried to do something similar but in a specific IT and it didn't work. Not sure if doing it in the parent would change something.

The way I understand it it needs to be in a parent pom so that it gets evaluated earlier and thus set the test-containers and pass it to lower pom files. If we do it inside the same pom file the evaluation is not recursive so both test-containers and start-containers will get the provided values and not the ones possibly defined by a profile.

I faced that same issue in #10932 (comment)

[gsmet]

I tried but it doesn't work.

[zakkak]

I tried but it doesn't work.

:( Thanks for trying it out @gsmet

[gastaldi]

Fantastic! Looks like I can check the first checkbox in #11622