> >> I'm in favor for opening a dedicated ticket and merge a disabled version
> >> of this test in order to document the problem.
> >>
> >
> > it"s been busy and I haven't opened the ticket yet, nor have we managed
> to
> > fully fix the issue yet
> >
>
> I can devote some of my time to support you on this.
>
Thanks, if you can open the jira issue I think I provided the relevant
information in my previous mail, and if you feel lucky you can take a look
at the branch I referred to the test demonstrating the issue is still there
:)
> We use a static singleton approach in order for testcontainers docker
> containers to be initialised once per surefire fork and not once per
> test class. Combined wih a reuseForks=true setting this dramatically
> reduce testing time!
>
> The only downside in cryptic NoClassDefound errors if the given docker
> container can't start.
>
That was extremely useful insight, I downloaded the full log and found the
following:
> {"message":"No such image: quay.io/testcontainers/ryuk:0.2.3"}
which repeats for most tests failures, this seems to be common enough that
there is stack overflow for it
https://stackoverflow.com/questions/61887363/testcontainers-cant-pull-ryuk-image-quay-io-is-not-reachable
I have attempted to upgrade test containers to 1.15.0 (as it will pull ryuk
from docker hub instead of quay.io since 1.14.3 and we were using 1.12)
hopefully this will help :)
To be noted that:
> - some tests reuse existing images
> - some tests like the LDAP one uses a Dockerfile to build their own
> image. This is likely the source of some instability.
>
I'll keep that in mind once the ryuk issue is fixed, thanks :)
> I also saw Cassandra containers failing initialization in memory
> constraint environments (eg on my laptop if less than 5GB are available).
>
RAM shouldn't be an issue on apache CI, the builders have 48GB of RAM :)
> A quick action could be to decrease surefire concurrency in some
> projects using expensive-to-start containers (like mailbox/cassandra,
> mpt/impl/imap/cassandra, etc...). If we can use en ENV variable for this..
I'll keep that in mind as a backup plan
thanks
Jean
