oscerd opened a new pull request, #26677:
URL: https://github.com/apache/camel/pull/26677

   ## What
   
   Compiles the WASM test fixtures from the Rego under test instead of 
committing them, and moves the tests that need a bundle to ITs.
   
   ## Why
   
   The `evaluationMode=wasm` tests loaded `authz.wasm`, a compiled binary 
committed next to `authz.rego`. Nothing tied the two together, and they came 
apart: the committed module predated the second `decision` rule in the Rego, so 
`OpaWasmEvaluatorTest` asserted that input was *undefined* while 
`OpaIT.keepsTheDenyReasonsFromADecisionObject` asserted it returns deny-reasons 
— against the same source file. **Both passed.** A suite whose entire purpose 
is "both engines decide the same way" was comparing two different policies 
(found during CAMEL-24741).
   
   A compiled binary in `src/test/resources` also has no business in an ASF 
source release.
   
   ## How
   
   `camel-test-infra-opa` gains `OpaWasmBundleBuilder`: a one-shot container 
run of `opa build -t wasm -e <entrypoint> .` using the image **already pinned 
in `container.properties`**, returning the bundle bytes. The module's role 
widens from *serving* policies to also *producing* them; the existing server 
service is untouched, since the REST ITs still need it.
   
   `OpaWasmIT` then compiles the very `authz.rego` that `OpaIT` uploads to a 
real server, so the parity claim is tested rather than asserted — the two 
classes now make matching assertions about the same rules through different 
engines.
   
   ## Does it actually close the hole?
   
   Yes, and that is the one thing worth checking. Deleting the `mallory` branch 
from `authz.rego` — the exact drift that occurred — now fails the WASM test:
   
   ```
   OpaWasmIT.keepsTheDenyReasonsJustLikeTheRestEngine:119
   Tests run: 9, Failures: 1
   ```
   
   Before this change that same edit left every WASM test green.
   
   ## Trade-off
   
   The 10 tests that evaluate a policy become ITs, so they run under `-Pit` 
rather than in a plain `mvn test`. The two that reject a configuration *before* 
any bundle is loaded stay unit tests in `OpaWasmConfigurationTest`, because 
they need neither an artifact nor a container.
   
   That is a real loss of fast feedback, and it is the cost of the fixtures 
being honest. The issue was filed two days before the WASM work merged, so it 
predates the tests it affects; both of its arguments still hold, which is why 
it is implemented as written rather than re-scoped.
   
   ## Two things found on the way
   
   **The fixtures were built with the wrong OPA.** They came from 
`opa:1.9.0-static` while `container.properties` pins `1.20.2-static` — a 
second, unnoticed drift between the compiler and the server the REST ITs run. 
Verified a `1.20.2` bundle loads in `opa-java-wasm` 1.1.0 before building on 
it, so one pinned image now serves both.
   
   **`opa build` cannot write into its own working directory.** The image runs 
as a non-root user while the directory Testcontainers creates is root-owned, so 
the build fails with `open bundle.tar.gz: permission denied`. Output goes to 
`/tmp` via `-o`. This was invisible until the copy-in path — a bind-mounted 
host directory is writable, so a manual `docker run` succeeds where the 
container-copy route does not. The builder now puts `opa build`'s own stderr 
into the exception; without it the failure reads only "Container startup 
failed", which says nothing about your Rego.
   
   ## Testing
   
   Five tests on the builder itself (emits `policy.wasm`, packs a `data.json` 
sitting beside the policy, rejects no-entrypoint and no-source, reports what 
`opa` disliked), nine in `OpaWasmIT`, two in `OpaWasmConfigurationTest`. 72 
unit tests and 20 ITs in `camel-opa`. Full reactor build green.
   
   ## Scope
   
   `main` only, tests and test-infra. No production code changes.
   
   _Claude Code on behalf of @oscerd_
   


-- 
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]

Reply via email to