Federico Mariani created CAMEL-24588:
----------------------------------------
Summary: camel-test-infra-ibmmq: abort (skip) IBM MQ tests instead
of failing when the container image cannot be pulled
Key: CAMEL-24588
URL: https://issues.apache.org/jira/browse/CAMEL-24588
Project: Camel
Issue Type: Improvement
Components: camel-jms, camel-test-infra
Reporter: Federico Mariani
Assignee: Federico Mariani
Fix For: 4.23.0
{{JmsComponentIbmMQTest}} and {{JmsReplyToIbmMQTest}} start
{{icr.io/ibm-messaging/mq:10.0.0.0-r3}} via Testcontainers. When icr.io is slow
or unreachable from CI, the pull hits the Testcontainers 2-minute limit and the
test class errors with {{ContainerFetchException}}. With
{{-Dsurefire.rerunFailingTestsCount=2}} the class is retried, so a single
registry hiccup costs ~18 minutes (292 s + 507 s + 292 s in PR #26024, run
33542426658) and fails the build for a reason unrelated to the code under test.
The JDK 25 matrix job is then cancelled by fail-fast.
Proposal: in {{IbmMQLocalContainerInfraService.initialize()}} catch
{{ContainerFetchException}}, log a warning, and throw
{{org.opentest4j.TestAbortedException}} so JUnit reports the class as aborted
(skipped). Cache the failure in a static field so subsequent IBM MQ test
classes in the same JVM abort immediately instead of waiting for the pull
timeout again. Aborted classes are not retried by Surefire.
Caveat: Surefire reports an aborted class as "Tests run: 0, Skipped: 0", so the
skip is visible only through the log warning.
h3. Other test-infra services that would benefit
50 test-infra modules start containers. The ones below are the most exposed,
either because their image is not on the mirrors the project prefers
({{mirror.gcr.io}}, {{quay.io}}), or because they are used by plain {{*Test}}
classes that run under Surefire in every PR build.
Images pulled from registries outside the preferred mirrors (amd64):
||Module||Image||
|camel-test-infra-ibmmq|{{icr.io/ibm-messaging/mq:10.0.0.0-r3}} (this issue)|
|camel-test-infra-azure-common|{{mcr.microsoft.com/azure-storage/azurite:3.37.0}}|
|camel-test-infra-elasticsearch|{{docker.elastic.co/elasticsearch/elasticsearch:9.1.0}}|
|camel-test-infra-google-pubsub|{{gcr.io/google.com/cloudsdktool/cloud-sdk:emulators}}|
|camel-test-infra-pinecone|{{ghcr.io/pinecone-io/pinecone-local:v1.0.0.rc0}}|
|camel-test-infra-redis|{{ghcr.io/joeferner/redis-commander:0.9.1}} (UI
companion)|
|camel-test-infra-triton|{{nvcr.io/nvidia/tritonserver:24.12-py3}}|
|camel-test-infra-weaviate|{{cr.weaviate.io/semitechnologies/weaviate:1.37.4}}|
|camel-test-infra-mcp-everything|{{tzolov/mcp-everything-server:v3}} (Docker
Hub, rate limited)|
|camel-test-infra-tensorflow-serving|{{ibmcom/powerai:...-ppc64le}} (Docker
Hub, ppc64le only)|
In addition, 18 modules use {{icr.io/ppc64le-oss/*}} images for the ppc64le
architecture only (artemis, consul, elasticsearch, fhir, hashicorp-vault,
infinispan, keycloak, microprofile-lra, milvus, mongodb, neo4j, ollama,
opensearch, pulsar, qdrant, rocketmq, weaviate, zookeeper). These only matter
on the ppc64le Jenkins nodes but share the same registry as the IBM MQ image.
Container-backed services referenced from {{*Test}} classes, so a pull failure
fails a PR build rather than an IT run:
||Module||Image||References from *Test.java||
|camel-test-infra-kafka|{{mirror.gcr.io/apache/kafka:4.3.1}} and variants|7|
|camel-test-infra-aws-v2|{{mirror.gcr.io/floci/floci:1.7.0}}|6|
|camel-test-infra-ibmmq|{{icr.io/ibm-messaging/mq:10.0.0.0-r3}}|4|
(Artemis and Hazelcast are also used from {{*Test}} classes but default to
embedded, in-JVM services, so they are not affected.)
h3. Alternative: fix it once in camel-test-infra-common
Instead of patching each service, the conversion of {{ContainerFetchException}}
into {{TestAbortedException}} could live in {{TestServiceUtil.tryInitialize()}}
(used by every {{TestService.beforeAll()}}) and
{{SingletonService.doInitializeService()}}, after the existing retry loop has
given up. That would cover all 50 container-backed modules with one change and
keep per-service classes untouched. The trade-off is that a genuinely
misconfigured image name would then be reported as a skip instead of a failure
everywhere, so it should probably be opt-in via a system property (for example
{{camel.test.infra.container.abortOnFetchFailure}}) that CI sets.
_Drafted by Claude Code on behalf of Croway_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
