You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "oscerd (via GitHub)" <gi...@apache.org> on 2026/08/25 07:40:06 UTC

[I] Citrus integration tests do not exercise the Kamelets built in the same run [camel-kamelets]

oscerd opened a new issue, #2984:
URL: https://github.com/apache/camel-kamelets/issues/2984

   While reviewing #2978 I hit a case where a Kamelet change that provably breaks a shipped Citrus test was reported green by the `Integration Tests` workflow.
   
   ## What happened
   
   PR #2978 (head `5767c186`) added this to `kafka-sink.kamelet.yaml`:
   
   ```yaml
         - removeHeader:
             name: CamelKafkaOverrideTopic
   ```
   
   `tests/camel-kamelets-itest/src/test/resources/kafka/kafka-router-pipe.yaml` is a Pipe of the shape:
   
   ```
   webhook-source -> timestamp-router-action -> set-body-action -> log-action -> kafka-sink (topic: dummy)
   ```
   
   `timestamp-router-action` wraps `org.apache.camel.component.kafka.transform.TimestampRouter`, whose only job is to set `CamelKafkaOverrideTopic`. `kafka-router-pipe.citrus.it.yaml` then consumes from the **overridden** topic (`${kafka.topic}_${date}`) — `dummy` is deliberately a throwaway. So the assertion depends entirely on that header surviving into the sink.
   
   Reproduced locally with Camel JBang, using a copy of the PR's `kafka-sink` steps ending in `log:` instead of `kafka:`:
   
   ```
   BEFORE SINK -> CamelKafkaOverrideTopic=prefix-my-topic
   PROBE       : Exchange[Headers: {CamelKafkaTopic=my-topic}, BodyType: String]
   ```
   
   The header is gone before dispatch. The test should have failed.
   
   It did not: [run 32739488298](https://github.com/apache/camel-kamelets/actions/runs/32739488298) on that head reports `✔ TEST SUCCESS: kafka-router-pipe-test`, and the message was received on `my-topic-3_2026-08-24`.
   
   The only consistent explanation is that the `kafka-sink` the integration used was not the one in the PR.
   
   ## Likely cause
   
   The `.citrus-jbang` dumps show Kamelets being loaded from the jar, not the working tree:
   
   ```
   YAML DSL compact notation detected in: classpath:kamelets/regex-router-action.kamelet.yaml
   ```
   
   `src/test/resources-filtered/citrus-application.properties` sets:
   
   ```properties
   citrus.camel.cli.version=${camel.version}                # 4.22.0
   citrus.camel.cli.kamelets.version=${project.version}     # 4.22.1-SNAPSHOT
   ```
   
   and the workflow does build and install the snapshot first (`./mvnw clean install -DskipTests -DskipITs`). But the dumps only confirm `Apache Camel (JBang) 4.22.0` — the resolved `camel-kamelets` GAV is never logged, so it is plausible that `citrus.camel.cli.kamelets.version` is not reaching the Camel CLI and JBang falls back to the released `camel-kamelets` matching the CLI version (4.22.0). That would exactly produce the observed result. Worth confirming rather than assuming — I could not verify it from the logs alone.
   
   ## Why it matters
   
   The Citrus suite is the catalog's only behavioural gate. If it silently runs against the previously released catalog, every Kamelet change is effectively untested in CI, and a regression in a shipped Kamelet only surfaces after release.
   
   ## Suggested next steps
   
   - Confirm which `camel-kamelets` artifact the Camel CLI actually resolves during the itest run (log the GAV, or use `--local-kamelet-dir` pointed at the repository `kamelets/` directory).
   - Once the wiring is fixed, `kafka-router-pipe-test` should be verified to fail against a `kafka-sink` that strips `CamelKafkaOverrideTopic`, as a regression check on the gate itself.
   
   For reference, #2978 has been updated so it no longer touches `kafka-sink` — this issue is about the CI gap only, not that change.
   
   ---
   _Claude Code on behalf of Andrea Cosentino_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Citrus integration tests do not exercise the Kamelets built in the same run [camel-kamelets]

Posted by "oscerd (via GitHub)" <gi...@apache.org>.
oscerd closed issue #2984: Citrus integration tests do not exercise the Kamelets built in the same run
URL: https://github.com/apache/camel-kamelets/issues/2984


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org