-
Notifications
You must be signed in to change notification settings - Fork 7
feat: kustomize for local & prod k8s #106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note: also this PR is [draft] and needs alignment and some cleanup to remove filoz-infra mentions (and cleanup of /docs) prior to merge. I wanted to get this out and get a pr review from copilot and will move this back to draft |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This comprehensive pull request establishes a complete local-to-production Kubernetes deployment workflow for the dealbot application. The PR introduces Helm charts for local Kind cluster development, implements GitOps-based CI/CD pipelines with automated Docker image building and semantic versioning via release-please, and provides extensive documentation for both standard releases and emergency hotfixes.
Key changes:
- Replaces docker-compose with Helm charts and Kind for local development, providing production-parity K8s environments
- Implements automated CI/CD with path-based change detection, dual image tagging (SHA for staging, semver for production), and ECR manifest-based image promotion
- Adds comprehensive hotfix workflow supporting emergency releases directly from hotfix branches
Reviewed changes
Copilot reviewed 40 out of 41 changed files in this pull request and generated 20 comments.
Show a summary per file
| File | Description |
|---|---|
| release-please-config.json | Configures release-please for independent versioning of backend and web apps with conventional commits |
| .release-please-manifest.json | Tracks current semantic versions for both applications starting at 0.0.1 |
| kind-config.yaml | Defines local Kind cluster with port mappings for backend (8080) and web (3000) services |
| Makefile | Provides comprehensive targets for building images, loading to Kind, deploying Helm charts, and managing secrets |
| .env.example | Template for local development secrets (wallet keys, optional DB password) |
| DEVELOPMENT.md | Complete guide for local Kubernetes development with Kind, Helm, and secret management |
| docs/release-process.md | Documents the automated staging-to-production release flow with Flux CD integration |
| docs/release-please-flow.md | Explains conventional commit-based versioning and release-please PR workflow |
| docs/infra.md | Describes integration between local Helm charts and production Kustomize manifests in filoz-infra |
| docs/hotfix-and-edge-cases.md | Comprehensive guide for emergency hotfixes and edge case handling |
| charts/dealbot/Chart.yaml | Helm chart metadata for backend service |
| charts/dealbot/values.yaml | Production-ready values for backend with security and scaling options |
| charts/dealbot/values.local.yaml | Local development overrides including bundled PostgreSQL |
| charts/dealbot/values.local.override.example.yaml | Template for gitignored local customizations |
| charts/dealbot/templates/*.yaml | Kubernetes manifests for deployment, service, ingress, HPA, PostgreSQL, ConfigMap, and ServiceAccount |
| charts/dealbot-web/Chart.yaml | Helm chart metadata for web frontend |
| charts/dealbot-web/values.yaml | Production-ready values for web service |
| charts/dealbot-web/values.local.yaml | Local development overrides with NodePort service |
| charts/dealbot-web/values.local.override.example.yaml | Template for gitignored web customizations |
| charts/dealbot-web/templates/*.yaml | Kubernetes manifests for web deployment, service, ingress, and HPA |
| apps/web/Dockerfile | Multi-stage build with Caddy server, runtime config generation, and reverse proxy |
| apps/web/docker-entrypoint.sh | Generates /config.json from environment variables at container startup |
| apps/web/src/api/client.ts | Implements runtime config loading with fallback to build-time values for API base URL |
| apps/postgres/Dockerfile | Minimal PostgreSQL image for local development based on postgres:16-alpine |
| .github/workflows/docker-build.yml | Builds and pushes Docker images with SHA-based tags on main branch merges |
| .github/workflows/release-please.yml | Creates release PRs and retags images with semver after PR merge |
| .github/workflows/hotfix-release.yml | Handles emergency hotfix releases from hotfix/** branches |
| .gitignore | Adds entries for local Helm override files |
| docker-compose.dev.yml | Removed in favor of Kubernetes-based local development |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| grep -E '^(WALLET_PRIVATE_KEY|WALLET_ADDRESS|DATABASE_PASSWORD|FILBEAM_BOT_TOKEN)=' "$(SECRET_ENV_FILE)" > "$$tmp_env_file" || true; \ | ||
| if ! grep -q '^WALLET_PRIVATE_KEY=' "$$tmp_env_file"; then echo "WALLET_PRIVATE_KEY is required (set in $(SECRET_ENV_FILE))"; exit 1; fi; \ | ||
| if ! grep -q '^WALLET_ADDRESS=' "$$tmp_env_file"; then echo "WALLET_ADDRESS is required (set in $(SECRET_ENV_FILE))"; exit 1; fi; \ |
Copilot
AI
Dec 17, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The WALLET_PRIVATE_KEY and WALLET_ADDRESS validation in the secret target doesn't verify that the values are non-empty, only that the keys exist. An empty value like 'WALLET_PRIVATE_KEY=' would pass validation but cause runtime failures. Consider adding validation to ensure these required secret values are not empty strings.
| # 6. ⚠️ CRITICAL: Merge hotfix back to main immediately | ||
| git checkout main | ||
| git pull origin main | ||
| git merge hotfix/v1.2.4 | ||
| git push origin main | ||
| # 7. Verify main has the fix | ||
| git log --oneline main -5 | ||
| # Should see your hotfix commit in main now | ||
| # Total time: ~10 minutes from push to production | ||
| # IMPORTANT: Don't skip step 6 or next release will reintroduce the bug! |
Copilot
AI
Dec 17, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The documentation states 'Do not skip step 6 or next release will reintroduce the bug!' but there's no automated check or safeguard to prevent this. Consider adding a GitHub Actions workflow or a pre-release check that verifies hotfix branches have been merged back to main before allowing new releases, or at least add a checklist item in the PR template to remind developers of this critical step.
|
Note that this is now deployed on my homelab k8s cluster and available at http://dealbot.bt.sgtpooki.com/ the diff is basically: View diff needed for infra repo |
83c3665 to
76e57ab
Compare
|
2026-01-05 conversation between @BigLep and @SgtPooki :
After this PR is done, there are FilOzone/infra changes. It still can be deployed to Coolify as is in the interim. @SgtPooki is going to make sure we have an issue(s) that lists the steps for getting us to a place where commits can be pushed to dealbot and they get deployed in a structured / reviewed way. |
Note: there are a lot of changes here, but there is a lot of documentation in /docs as well. check those out first to get a firm grasp of what's going on here.
Also note that due to the latest on FilOzone/tpm-utils#1, the
filoz-infraexpectations (ECR, AWS KMS, etc..) will change.This pull request introduces a comprehensive local Kubernetes development workflow using Kind and Helm, adds robust CI/CD pipelines for Docker image builds and releases (including hotfixes), and establishes best practices for secret management and environment configuration. The changes streamline both local development and production release processes, ensuring consistency and security across environments.
Local development and Kubernetes workflow:
DEVELOPMENT.mdwith detailed instructions for setting up and managing a local Kind cluster, handling secrets, deploying with Helm, and managing persistent storage for PostgreSQL.Makefilewith targets for building images, loading them into Kind, deploying via Helm, managing secrets, and orchestrating combined workflows for backend and web services..env.examplefor local secret management, clarifying which secrets are required and how they are consumed in local dev.apps/postgres/Dockerfilebased onpostgres:16-alpinefor local database development.CI/CD and release automation:
.github/workflows/docker-build.ymlto build and push backend and web Docker images to ECR, with change detection for efficient builds..github/workflows/release-please.ymlto automate versioning and retagging of Docker images after successful builds, using Release Please and ECR manifests..github/workflows/hotfix-release.ymlto support hotfix releases fromhotfix/**branches, immediately building and pushing hotfix images upon release creation..release-please-manifest.jsonto track and version backend and web applications.