feat: add NATS local server support to integration test#23
Conversation
Trivy Scan ResultsVulnerabilities Found |
There was a problem hiding this comment.
Pull request overview
Adds opt-in local NATS server support to the shared GitHub Actions integration test workflow so services that require NATS (e.g., those using github.com/wanaware/common/nats) can start successfully during CI runs.
Changes:
- Introduces a
use_natsworkflow input (defaultfalse) to optionally start a localnats-serverduring integration tests. - Downloads and runs
nats-serveron4222with HTTP monitoring on8222, exportsNATS_URLfor the test run, and adds a health check. - Extends the existing cleanup step to terminate the NATS process.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Trivy Scan ResultsVulnerabilities Found |
Greptile SummaryThis PR adds an opt-in
Confidence Score: 5/5Safe to merge — the change is fully opt-in and does not affect existing callers. The NATS lifecycle follows the same pattern as the existing Redis integration and is guarded by a default-false flag, so no existing workflows are touched. The two previously-flagged concerns (missing --retry-connrefused and absent checksum verification) are already under review. The only new finding here is a redundant apt-get install without a preceding apt-get update, which would not cause failures on standard GitHub-hosted runners where unzip is pre-installed. No files require special attention beyond the single changed workflow. Important Files Changed
Sequence DiagramsequenceDiagram
participant W as Workflow
participant N as NATS Server
participant A as App Server
Note over W: use_nats == true
W->>N: Download nats-server v2.10.18 binary
W->>N: "nohup nats-server --port 4222 --http_port 8222 &"
W->>W: echo NATS_SERVER_PID to $GITHUB_ENV
W->>W: sleep 2
W->>W: echo NATS_URL to $GITHUB_ENV
W->>N: curl --retry 5 /healthz (Ping step)
N-->>W: 200 OK
W->>A: Start App Server (inherits NATS_URL from env)
Note over W,A: Integration tests run
W->>A: kill $API_PID
W->>N: kill $NATS_SERVER_PID
Reviews (2): Last reviewed commit: "feat(TMF-2456): AI comments" | Re-trigger Greptile |
Trivy Scan ResultsVulnerabilities Found |
Summary
Add optional NATS server support to the shared integration test workflow (
integration-tests.yaml).A new
use_natsboolean input (defaultfalse) controls whether a local NATS server is spun up during the test run. When enabled, the workflow:nats-server v2.10.18binary from GitHub releases4222with the HTTP monitoring port on8222curl http://127.0.0.1:8222/healthzwith 5 retriesNATS_URL=nats://127.0.0.1:4222as an environment variable for the Go serverWhy
Services that use
github.com/wanaware/common/nats(e.g.worker-proxy-service) require a live NATS connection at startup. Without a local NATS server in CI, those services fail to boot during integration tests.This follows the same opt-in pattern already used for Redis (
use_redis) and Cloud SQL (use_cloud_sql), keeping the change fully backward-compatible — existing callers likefunction-integratorare unaffected and require no changes.QA Report
Integration Tests
Added
Start Local NATS Server— downloadsnats-server v2.10.18, starts on port4222with HTTP monitoring on8222, saves PID to$NATS_SERVER_PID, setsNATS_URLin$GITHUB_ENVPing Local NATS—curlwith 5 retries againsthttp://127.0.0.1:8222/healthzto confirm the server is ready before the Go server startsEdited
Close App Server & cloud sql proxy— added[ -n "$NATS_SERVER_PID" ] && kill $NATS_SERVER_PID || trueto ensure NATS is always cleaned upDependencies
Callers that need NATS must opt in explicitly: