ci: end-to-end deploy smoke test on an ephemeral kind cluster - #318
Conversation
|
Warning Review limit reached
Next review available in: 47 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds ChangesDeploy Smoke Test Workflow
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
There was a problem hiding this comment.
Pull request overview
Adds a scheduled/on-demand GitHub Actions workflow that performs an end-to-end “deploy + ingest + query” smoke test by standing up an ephemeral kind cluster, deploying the Ourios Helm chart against an in-cluster LocalStack S3 backend, and validating the real OTLP ingest/query path.
Changes:
- Introduces a new
deploy-test.ymlworkflow that builds and kind-loads anourios-serverimage, deploys LocalStack, and installs the Helm chart configured for S3. - Exercises the running deployment by ingesting OTLP/JSON logs via the receiver and querying them back via the querier, with failure diagnostics.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/deploy-test.yml (1)
134-136: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winReceiver label selector matches two Services; pin the target instead.
app.kubernetes.io/component=receivermatches both the client-facingourios-receiverand the headlessourios-receiver-headlessService (seedeploy/helm/ourios/templates/services.yaml).items[0]then depends on kubectl's name ordering. Both happen to exposeotlp-http:4318so it works today, but selecting the headless Service for aport-forwardis fragile. Since the release name is fixed, target the client Service by name.♻️ Pin the receiver Service
- recv="$(kubectl get svc -l app.kubernetes.io/component=receiver -o jsonpath='{.items[0].metadata.name}')" - kubectl port-forward "svc/${recv}" 4318:4318 >/tmp/pf-recv.log 2>&1 & + kubectl port-forward svc/ourios-receiver 4318:4318 >/tmp/pf-recv.log 2>&1 &🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-test.yml around lines 134 - 136, The receiver Service selection in the deploy-test workflow is ambiguous because the label selector can return both the client-facing and headless Services. Update the port-forward setup in the workflow step that assigns recv and runs kubectl port-forward to target the client Service by its fixed name instead of relying on app.kubernetes.io/component=receiver plus items[0]. Keep the rest of the trap and port-forward logic unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-test.yml:
- Around line 161-172: The retry loop in the deploy-test workflow is being
short-circuited by bash errexit when curl or jq fails inside command
substitutions. Update the query polling block to make the `out` and `rows`
assignments tolerant of transient failures so the loop continues through all
attempts instead of exiting on the first bad response. Use the existing retry
logic around the curl/jq calls in the smoke-test step to keep failures falling
through until the final check.
---
Nitpick comments:
In @.github/workflows/deploy-test.yml:
- Around line 134-136: The receiver Service selection in the deploy-test
workflow is ambiguous because the label selector can return both the
client-facing and headless Services. Update the port-forward setup in the
workflow step that assigns recv and runs kubectl port-forward to target the
client Service by its fixed name instead of relying on
app.kubernetes.io/component=receiver plus items[0]. Keep the rest of the trap
and port-forward logic unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 6198f0ef-de7c-4fb8-bbd8-023819b87643
📒 Files selected for processing (1)
.github/workflows/deploy-test.yml
3a2e1d3 to
6a77a11
Compare
Deploy the Helm chart to a kind cluster against an in-cluster LocalStack (the chart's S3 production path), then exercise the real path: push an OTLP/JSON log batch at the receiver and read it back through the querier. No persistent cluster exists, so CI is the deploy target (managed K8s + bare metal come later). On-demand + nightly (not per-PR): a kind boot + image build + deploy is too heavy to gate every PR. Notes: tenant == the service.name resource attribute, so ingest and the query's X-Ourios-Tenant match; ingested records buffer in the sink until a size/age (300s) flush, so the test restarts the receiver to force the graceful-shutdown drain to S3 before querying; the image is built from the checkout and kind-loaded (no registry pull). Port-forward targets the explicit ClusterIP services (the component label also matches the headless receiver service). The curl loops tolerate transient failures (bash -e) so retries work. Actions + the LocalStack image are pinned; least-privilege. A temporary path-scoped pull_request trigger validates this on its own PR (workflow_dispatch can't target a non-default branch); removed before merge. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
26729fe to
9c52fc5
Compare
Validated end-to-end on this PR (kind deploy + OTLP ingest → query, rows=1) with the explicit ClusterIP service targets, errexit-tolerant retry loops, and pinned LocalStack. Revert to on-demand + nightly only — not a per-PR gate. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
What
A nightly / on-demand end-to-end deploy smoke test: spin up an ephemeral kind cluster, deploy the Ourios Helm chart against an in-cluster LocalStack (the chart's S3 production path), then exercise the real path — push an OTLP/JSON log batch at the receiver and read it back through the querier.
This is the "see the chart actually run" validation. The old Talos cluster is gone and there's no persistent cluster, so CI is the deploy target for now; managed K8s (AKS/GKE) + bare metal are a later infra workstream.
Flow
ourios-serverimage from the checkout,kind loadit (no registry pull).helm installwithbackend=s3, endpoint→LocalStack, creds Secret,image.pullPolicy=Never.service.name=ourios-smoke) at:4318/v1/logs.rollout restartthe receiver — records buffer in the sink until a size/age (300 s) flush, and graceful shutdown drains the sink to S3.:4319/v1/query(service == "ourios-smoke",X-Ourios-Tenant: ourios-smoke) and assertrows >= 1.Notes
service.nameresource attribute, so the ingested service name and the query tenant header must match.template_createdaudit events).permissions: contents: read; failure step dumps pod/describe/logs.actionlint+helm lint+helm template(renders, names match). The real run can only be exercised in CI — validating viaworkflow_dispatchon this branch before merge.🤖 Generated with Claude Code
Summary by CodeRabbit