|
| 1 | +# AGENTS |
| 2 | + |
| 3 | +## Repository structure |
| 4 | +- `/chart/Chart.yaml`: Helm chart metadata (name, version, description). **Do not bump the version manually**—it is updated automatically during release workflows. |
| 5 | +- `/chart/values.yaml`: Default configuration for all OpenOps components; use it to learn the expected keys before adding overrides. |
| 6 | +- `/chart/values.overrides-example.yaml`: Reference file that shows how to structure your own overrides file for deployments. |
| 7 | +- `/chart/values.ci.yaml`: Resource-constrained overlay for CI environments. |
| 8 | +- `/chart/values.dev.yaml`: Development overlay for local development environments. |
| 9 | +- `/chart/values.production.yaml`: Production overlay with externalized dependencies and cloud settings. |
| 10 | +- `/chart/templates/`: Kubernetes manifests rendered by Helm (43 files). Includes deployments/statefulsets, services, configmaps (`configmap-*.yaml`), secrets (`secret-env.yaml`, `external-secret.yaml`), service accounts, PodDisruptionBudgets, HorizontalPodAutoscalers, NetworkPolicy, LimitRange, ServiceMonitor for Prometheus, and Helm tests. Shared template helpers live in `_helpers.tpl` (561 lines with 49+ helper functions). Postgres and Redis use StatefulSets with volumeClaimTemplates for stable storage and safe rollouts. |
| 11 | +- `/chart/templates/NOTES.txt`: Helm installation notes displayed after deployment with important warnings and next steps. |
| 12 | +- `/chart/.helmignore`: Excludes development and repository files from packaged charts to reduce size and prevent leaking unnecessary files. |
| 13 | +- `/LICENSE`: Apache 2.0 license for this Helm chart repository. |
| 14 | +- `/README.md`: Comprehensive documentation covering installation, configuration, operational toggles (secrets, TLS, scaling, production hardening), and multi-environment deployments. |
| 15 | +- `/docs/`: Deployment guides including AWS EKS (EC2), AWS EKS Fargate, and platform-specific instructions. |
| 16 | +- `/.github/prlint.json`: Pull-request lint configuration (see below) that runs in CI to enforce title/body rules. |
| 17 | +- `/.github/workflows/`: Automation (tests, lint, release) triggered by pushes and pull requests. Update these only when you need to change CI behavior. |
| 18 | + |
| 19 | +## Stateful dependencies |
| 20 | +- **Postgres and Redis** are deployed as StatefulSets with volumeClaimTemplates for per-pod persistent storage, ordered rollouts, and stable network identities. |
| 21 | +- Both support optional authentication, TLS encryption, and backup annotations for production use. |
| 22 | +- Set `replicas: 0` in production overlays to use external managed services (AWS RDS, ElastiCache, etc.) instead of in-cluster instances. |
| 23 | +- **Tables** uses a PersistentVolumeClaim for `/baserow/data` and includes an init container to fix volume ownership (uid:gid 1000:1000) to ensure compatibility with non-root security contexts. |
| 24 | + |
| 25 | +## Production features |
| 26 | +- **Security-first design**: Security contexts enabled by default (runAsNonRoot, drop ALL capabilities, seccomp RuntimeDefault profile). |
| 27 | +- **Service accounts**: Dedicated service accounts for each component (app, engine, tables, analytics, nginx, postgres, redis) with configurable annotations for AWS IAM roles (IRSA), GCP Workload Identity, or Azure Managed Identity. |
| 28 | +- **External Secrets Operator**: Built-in support for AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, and Azure Key Vault integration. |
| 29 | +- **PodDisruptionBudgets (PDBs)**: Configured for all stateless components to ensure minimum availability during voluntary disruptions (node drains, upgrades). |
| 30 | +- **HorizontalPodAutoscalers (HPAs)**: Optional autoscaling for app, engine, analytics, and nginx based on CPU/memory metrics. |
| 31 | +- **NetworkPolicy**: Optional network segmentation to restrict pod-to-pod communication and enforce least-privilege networking with explicit allow rules. |
| 32 | +- **LimitRange**: Optional namespace-level resource defaults and constraints to prevent resource exhaustion. |
| 33 | +- **ServiceMonitor**: Prometheus Operator integration for scraping application metrics from `/metrics` endpoints. |
| 34 | +- **Helm tests**: Post-installation connectivity tests to validate deployment health. |
| 35 | +- **Validation helpers**: Runtime validation of required secrets (OPS_ENCRYPTION_KEY, OPS_JWT_SECRET, etc.) with helpful error messages at render time. |
| 36 | + |
| 37 | +## PR lint rules |
| 38 | +The `.github/prlint.json` ruleset runs on every pull request. To avoid CI failures: |
| 39 | +1. **Title requirements** |
| 40 | + - Start with a capitalized real word (`Add`, `Fix`, `Update`, etc.). |
| 41 | + - Contain at least three words so reviewers immediately understand the change. |
| 42 | + - Use the imperative mood ("Add support for X" rather than "Added" or "Adding"). |
| 43 | +2. **Body requirements** |
| 44 | + - Reference the tracking item with one of `Fixes|Resolves|Closes|Part of` followed by either a GitHub issue (`#1234`) or a Linear ticket (`OPS-1234`, `OPC-1234`, `CI-1234`, `DOC-1234`). |
| 45 | + - For dependency bumps, "Dependabot commands and options" is also accepted. |
| 46 | + |
| 47 | +## License |
| 48 | +This Helm chart repository is licensed under the Apache License 2.0. See the LICENSE file for full terms. |
| 49 | + |
| 50 | +## Documentation updates |
| 51 | +- **Update both AGENTS.md and README.md** with every PR if there are relevant changes to repository structure, workflows, guidelines, or usage instructions. |
| 52 | +- Keep documentation synchronized with code changes to ensure agents and users have accurate information. |
| 53 | +- The chart is production-ready and follows enterprise-grade best practices for security, high availability, and observability. |
| 54 | + |
| 55 | +## Commit guidelines |
| 56 | +- Write commit subjects in the imperative mood, mirroring the PR title rules (e.g., "Add Redis PVC annotations"). |
| 57 | +- Capitalize the first word and keep the subject ≤ 72 characters; add a blank line before the body. |
| 58 | +- Use the body to explain *what* and *why*, wrapping at ~72 characters per line for readability. |
| 59 | +- Reference relevant issues in the body when closing or relating work (same keywords as PR bodies). |
| 60 | +- Prefer focused commits that touch a single logical change; this keeps review and potential rollbacks simple. |
0 commit comments