fix(xtest): pull Keycloak 26.4 bootstrap on the main platform lane - #576
Conversation
The start-up-with-containers action overlays docker-compose.yaml from a frozen ref, not from platform-ref. That ref defaulted to the pqc-enabled tag, which still pins keycloak/keycloak:25.0 -- so every lane ran a Keycloak that cannot issue DPoP-bound access tokens, even though platform main's own compose has been on ghcr.io/opentdf/keycloak-standard:26.4.0 with KC_FEATURES: dpop since opentdf/platform#3792. The visible symptom is test_dpop.py::test_dpop_happy_path_roundtrip failing for any SDK that checks token binding: the token comes back typ=Bearer with no cnf.jkt, and the js CLI rejects it. The other test_dpop.py cases already skip themselves on token_type != DPoP. Bump the action pin to #3792 (input set is a strict superset) and pass bootstrap-ref: main for the main lane only. Released platform tags stay on the 25.0 bootstrap -- they predate the move to standard Keycloak token exchange. Signed-off-by: Dave Mihalcik <dmihalcik@virtru.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe platform test workflow updates the startup action revision. It selects the ChangesPlatform startup workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|



What
Bump the
start-up-with-containerspin to18b8070f(opentdf/platform#3792) and passbootstrap-ref: mainon themainplatform lane only.Why
The action overlays
docker-compose.yamlfrombootstrap-ref, independent ofplatform-ref. That input defaults to thepqc-enabledtag, which is still pinned tokeycloak/keycloak:25.0— a Keycloak that cannot issue DPoP-bound access tokens. So every lane ran KC 25 even though platformmain's own compose has beenghcr.io/opentdf/keycloak-standard:26.4.0withKC_FEATURES: dpopsince #3792, andservice/cmd/keycloak_data.yamlprovisionsopentdf-dpopwithdpop.bound.access.tokens: "true".The visible symptom:
test_dpop.py::test_dpop_happy_path_roundtripfails for any SDK that checks token binding. The token comes backtyp=Bearerwith nocnf.jkt, and the js CLI rejects it:go and java pass only because they don't assert
cnf.jkt. The othertest_dpop.pycases already self-skip ontoken_type != DPoP; the SDK-level roundtrips gate on the platform well-known and SDK features, not on IdP capability, so they run and fail. This is what keeps opentdf/web-sdk#939 red.Released platform tags keep the 25.0 bootstrap — they predate the move to standard Keycloak token exchange (opentdf/platform#3754).
Testing
Dispatched against this branch with
platform-ref=main,js-ref=refs/pull/939/merge,focus-sdk=js— https://github.com/opentdf/tests/actions/runs/31016132383 — all three lanes green (go@main,java@main,js@pull-939).Confirmed Keycloak 26.4 came up, and these ran rather than skipped:
The nonce-dependent cases still skip, correctly —
dpop-challengeis off by default, sorequire_nonceis unset.Notes
bootstrap-ref.start-additional-kasis left at6dd5f649— it downloads no compose.pqc-enabledtag, alignvulnerability.yml) still stands.Summary by CodeRabbit