oscerd opened a new pull request, #25096: URL: https://github.com/apache/camel/pull/25096
# CAMEL-22887: camel-cyberark-vault - add test-infra for automated testing https://issues.apache.org/jira/browse/CAMEL-22887 Adds `camel-test-infra-cyberark-vault` so the CyberArk Conjur integration tests run automatically instead of requiring a hand-provisioned Conjur instance. Before this change the ITs were gated on four `@EnabledIfSystemProperty` conditions and silently skipped in every normal build. They now run: **14 tests, 0 skipped**. ## Why it needs two containers Conjur cannot run standalone - it requires a PostgreSQL backend. The service therefore starts both containers on a private `Network` and exposes only Conjur, following the same pattern as `RocketMQContainerInfraService`. Conjur also has no admin credentials until an account exists, so the service runs `conjurctl account create` inside the container on startup and captures the generated API key. That is retried with Awaitility because Conjur starts accepting connections slightly before it can serve them. ## Builds on CAMEL-24236 CAMEL-24236 established that a Conjur secret is two separate things: a `variable` declared by policy, and a value assigned through the Secrets API - the Secrets API cannot create the variable. Setting a value for an undeclared variable returns `404`. That work already moved the ITs onto a `CyberArkTestSupport` base class with `loadPolicy` / `createSecret` helpers, so this PR mostly swaps the system-property plumbing underneath it for the test infra service. ## Changes - New `camel-test-infra-cyberark-vault` module, registered in `test-infra/pom.xml` and `camel-test-infra-all` (dependency + `fileSet`) - `camel-cyberark-vault` drops the hardcoded failsafe `systemPropertyVariables` and consumes the service instead; ITs now read connection details from `service.url()` / `.account()` / `.username()` / `.apiKey()` - Collapsed the repeated four-line vault wiring in the ITs into a `configureVault()` helper - Rewrote the IT README, which documented a manual setup flow that no longer applies ## Architecture support The `cyberark/conjur` image is published for `amd64` and `arm64` only - there is no `ppc64le` or `s390x` variant on any registry - so the ITs are disabled on those via `skipITs.ppc64le` and `skipITs.s390x`. ## Note on the service alias The metadata generator merges every module's `container.properties` into a single map and matches keys by alias suffix. Using `serviceImplementationAlias = "vault"` here collided with `camel-test-infra-hashicorp-vault` and silently rewrote its `serviceVersion`. This module therefore uses the alias `conjur` and the prefixes `cyberark.conjur.container` / `cyberark.conjur.database.container`, with a comment in `container.properties` recording the constraint. Worth hardening the mojo to flag ambiguous matches rather than silently pick one, but that is out of scope here. ## Testing Full IT suite green against real containers: ``` Tests run: 14, Failures: 0, Errors: 0, Skipped: 0 - BUILD SUCCESS ``` Verified via a `docker events` capture that the run really starts `mirror.gcr.io/cyberark/conjur:1.24.0` and `mirror.gcr.io/postgres:17.10-alpine` (three pairs - failsafe forks a JVM per test class) and destroys them all afterwards. Full reactor build green (679/679); `formatter:format` and `impsort:sort` produce no changes. --- _Claude Code on behalf of oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
