fix(ci): always generate opentdf.yaml even when PQC keys are absent - #3750
Conversation
PR #3594 added an early `exit 0` to the "Map the config to the keys" step to skip PQC config when the platform under test lacks PQC key generation. But that step is also where the base opentdf.yaml is created (`<opentdf-dev.yaml >opentdf.yaml yq e ...` at the end of the step), so the guard skipped opentdf.yaml creation entirely whenever kas-xwing-private.pem was missing (e.g. testing released tags like v0.9.0 that predate service/cmd/keygen). Every later step then failed with "stat opentdf.yaml: no such file or directory". Remove the misplaced guard. PQC extra keys are already filtered by the allowed_algorithms allowlist (which no longer lists hpqt:*), and the dedicated "Enable PQ ... wrapping" step keeps its own file-existence guard, so PQC is still correctly skipped when unsupported.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a regression in the CI pipeline where the opentdf.yaml configuration file failed to generate for older platform versions. By removing a premature exit guard, the process now correctly proceeds to generate the base configuration while still safely skipping PQC-specific steps where appropriate. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. The config file was nowhere to be found, / Because the script had exited on the ground. / We removed the guard that blocked the way, / Now tests will run throughout the day. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request removes the check for the presence of the 'kas-xwing-private.pem' file and the corresponding early exit logic in the 'test/start-up-with-containers/action.yaml' script. There are no review comments, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughThe container startup key-mapping script now conditionally adds RSA and ECC algorithms for newer platform versions and no longer exits when the PQC private key file is absent. ChangesAlgorithm allowlist update
Estimated code review effort: 2 (Simple) | ~5 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
Ppins the `start-up-with-containers` action to the fix branch for testing. ## Why opentdf/platform#3594 introduced a regression: a misplaced `exit 0` in the `Map the config to the keys` step of `test/start-up-with-containers/action.yaml` skips creation of `opentdf.yaml` whenever the platform under test lacks PQC keys (e.g. released tags like v0.9.0 that predate `service/cmd/keygen`). Every later step then fails with `stat opentdf.yaml: no such file or directory`. Fix: opentdf/platform#3750 (branch `fix/ci-startup-yaml-pqc-guard`, `c4038bdd72b8777654aa36266ad721710d220f4d`). ## Change - `.github/workflows/xtest.yml`: pin `start-up-with-containers` from `0612ea89 # main` → `c4038bd` (the fix branch) so CI exercises the fix. - `.github/workflows/vulnerability.yml` is intentionally **left** at `11af44a5 # pqc-enabled` — it's on a different lineage and isn't affected by this bug. ## Follow-up - Merge opentdf/platform#3750, then re-pin this back to the resulting `main` SHA. - A more principled replacement for the version/file heuristics (capability probe via keygen) is planned separately.
X-Test Failure Report |
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
|
Follow-up to #559. Now that [opentdf/platform#3750](opentdf/platform#3750) has merged, re-pin the `opentdf/platform` test actions from the temporary fix branch / stale main SHA to a **stable, named snapshot** of current platform main. To avoid the pins reading as "floating `main`", the target SHA is tagged in opentdf/platform as **`ci-startup-yaml-fix`** (annotated tag → `6dd5f649347fb2314c6090ea6d090a5c673d58a6`). Pins stay SHA-locked (supply-chain best practice); the tag is the human-readable comment. ## Changes (`.github/workflows/xtest.yml`) | Action | Before | After (SHA `6dd5f649`, tag `ci-startup-yaml-fix`) | |---|---|---| | `start-up-with-containers` (L309) | `c4038bd` (fix branch) | ✅ | | `start-additional-kas` ×6 (L604–670) | `0612ea89` (stale main) | ✅ | ## Notes - `6dd5f649` is the squash-merge of #3750 ("always generate opentdf.yaml") and was current platform `main` HEAD; the `ci-startup-yaml-fix` tag makes it a durable pointer. - `start-additional-kas/action.yaml` is **unchanged** between `0612ea89` and `6dd5f649` (verified via `compare`) — a SHA-only sync. - `vulnerability.yml` intentionally left on its `# pqc-enabled` pin (separate lineage).
2 participants
Problem
The reusable
platform-xtestjob (e.g. run 29361028930, jobxct (v0.9.0, go@main)) fails in Check out and start up platform with:thrown by the
Enable ECC wrapping for TDFsstep (yq ... -i opentdf.yaml).Root cause
opentdf.yamlis never created. Intest/start-up-with-containers/action.yaml, the only command that generates it —<opentdf-dev.yaml >opentdf.yaml yq e "${yq_command}"— is the last line of theMap the config to the keysstep.#3594 inserted an early
exit 0near the top of that same step:When the platform under test lacks PQC key generation (e.g. released tags like v0.9.0, which predate
service/cmd/keygen),kas-xwing-private.pemis never produced, the step bails before writingopentdf.yaml, and every later step that edits it fails.Fix
Remove the misplaced guard from the base-config step. This is safe:
allowed_algorithmsallowlist, which no longer listshpqt:*(also from fix(ci): DSPX-3499 skip PQC key config when platform lacks PQC support #3594) — so a PQC extra key is skipped by the loop'scontinue, not fatal.Enable PQ (mlkem, xwing, and hybrid) wrappingstep keeps its ownif [ ! -f kas-xwing-private.pem ]guard, so PQC config is still correctly skipped when unsupported.Net effect:
opentdf.yamlis always generated with the base + allowed keys; PQC is still skipped when the platform can't produce PQC keys.Verification
Simulated the patched step in a scratch dir with no
kas-xwing-private.pemandPLATFORM_VERSION=0.9.0:opentdf.yamlis now produced andyq e '.services.kas.preview.ec_tdf_enabled = true' -i opentdf.yamlsucceeds.A follow-up will replace the version/file heuristics with a more principled capability probe.
Regression from #3594.
Summary by CodeRabbit