[muhammad-tahir-nawaz]

Summary

With use_nats_port_forward, the integration-tests workflow now writes the NATS CA from the nats/nats-ca ConfigMap to /tmp/nats-ca.crt and points NATS_TLS_CA_FILE at it.

Why

The service env's NATS_TLS_CA_FILE is the pod's mount path (/etc/nats/certs/ca.crt), which does not exist on a runner, so the service under test fails its NATS TLS handshake before it starts (asset-pipeline#75: error loading or parsing rootCA file). Same pattern as the Vault CA (#56) and as RDE/kde's smoke workflows: the CA is public, CI has no access to Secrets, and container.configMaps.get is already in the CI role.

QA Report

• No QA report required — CI workflow change, no user-facing API.

Integration Tests

• No integration tests required — CI workflow only; exercised by re-running asset-pipeline#75's asset-normalizer integration test.

Dependencies

• None. nats/nats-ca is already published in dev.

[Copilot]

🟢 Approval recommended

The focused workflow change follows the established Vault CA pattern and correctly addresses the unavailable pod mount path.

0 open findings

What changed in this PR

Updates integration tests to load the NATS TLS CA from the cluster ConfigMap for port-forwarded NATS connections.

Changes:

• Fetches nats-ca and writes it to /tmp/nats-ca.crt.
• Exports the runner-accessible path through NATS_TLS_CA_FILE.
• Rejects an empty CA bundle.

File	Description
.github/​workflows/​integration-tests.yaml	Configures the NATS CA for integration-test runners.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge.

Summary

When use_nats_port_forward is enabled, the workflow reads the NATS CA from the nats/nats-ca ConfigMap.

• NATS port-forward tests load their CA from the runner.

_{Reviews (1) · Last reviewed commit: "fix: read the nats ca from a configmap i..." · Reviewed by Greptile}