oscerd opened a new pull request, #2987:
URL: https://github.com/apache/camel-kamelets/pull/2987
Fixes #2984.
The Citrus integration tests were resolving the Kamelet catalog from a
**released** `camel-kamelets` artifact rather than the one built in the same
run. The suite is the catalog's only behavioural gate, so in practice every
Kamelet change was going through CI untested.
## How it was found
PR #2978 briefly added this to `kafka-sink`:
```yaml
- removeHeader:
name: CamelKafkaOverrideTopic
```
`tests/.../kafka/kafka-router-pipe.yaml` is a Pipe of the shape
`webhook-source → timestamp-router-action → … → kafka-sink (topic: dummy)`, and
its Citrus assertion consumes from the **overridden** topic — `dummy` is
deliberately a throwaway. That strip nullifies the override, so the test should
have failed. It reported `TEST SUCCESS`.
## Cause
`citrus-application.properties` sets:
```properties
citrus.camel.cli.kamelets.version=${project.version}
```
Citrus turns that into the JBang system property `camel-kamelets.version`
via `ProcessLauncher.withSystemProperty`. But Camel JBang consumes that name as
a **JBang script property**, substituted into the `//DEPS` line of
`CamelJBang.java`:
```java
//DEPS
org.apache.camel.kamelets:camel-kamelets:${camel-kamelets.version:4.21.0}
```
A JVM system property never reaches that substitution, so the declared
version had no effect and the run fell back to the released catalog. The
integration dumps show it plainly — Kamelets loading from
`classpath:kamelets/<name>.kamelet.yaml`.
## Fix
Citrus 5.0.0 also exposes `citrus.camel.cli.kamelets.local.dir`, which it
turns into the Camel CLI's `--local-kamelet-dir` argument. Pointing that at the
repository `kamelets/` directory makes catalog resolution deterministic and
independent of artifact resolution — Camel orders the `file:` location ahead of
the classpath one, so the working tree always wins.
```xml
<kamelets.local.dir>${project.basedir}/../../kamelets</kamelets.local.dir>
```
```properties
citrus.camel.cli.kamelets.local.dir=${kamelets.local.dir}
```
`citrus.camel.cli.kamelets.version` is left in place — it still declares
intent for the `camel-kamelets` artifact on the JBang classpath, it simply is
not what selects the templates.
## Verification
Ran `KafkaIT` locally, both ways.
**1. The catalog under test is now the working tree.** Integration dumps
changed from `classpath:kamelets/…` to:
```
in: file:/…/camel-kamelets/kamelets/kafka-sink.kamelet.yaml
in: file:/…/camel-kamelets/kamelets/timestamp-router-action.kamelet.yaml
in: file:/…/camel-kamelets/kamelets/set-body-action.kamelet.yaml
in: file:/…/camel-kamelets/kamelets/webhook-source.kamelet.yaml
```
All 3 KafkaIT tests still pass against the working-tree catalog.
**2. The gate now catches the regression it previously missed.**
Re-introducing the exact `CamelKafkaOverrideTopic` strip from #2978:
```
✔ SUCCESS (43475ms) kafka-sink-pipe-test
✔ SUCCESS (57647ms) kafka-source-pipe-test
✘ FAILED (54935ms) kafka-router-pipe-test
TOTAL: 3 PASSED: 2 (66.7%) FAILED: 1 (33.3%)
BUILD FAILURE
```
That is the same test, on the same Pipe, that reported success on #2978's
head. Working tree restored afterwards — the diff here is two files, 9 added
lines.
`mvn clean install` passes from the repository root.
## Note for reviewers
This makes CI stricter, so the first run may surface pre-existing
Kamelet/test drift that the released catalog was masking. That would be a real
finding rather than a fault of this change, but worth watching on the first
green.
---
_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]
