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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
