4 Commits

Include renames

Author	SHA1	Message	Date
ClaudeandClaude Opus 5.5	584779945d	Give PostgreSQL enough CPU to pass its liveness probe ... With a 150m CPU limit, pg_isready routinely exceeds the 5s probe timeout under load (e.g. Gitea's startup migration check), so the kubelet kills postgres mid-query. This is the cause of the long-running restart loop on gitea-postgresql-0. Raise the limit to one core (request 250m). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-06 13:28:29 -05:00
ClaudeandClaude Opus 5.5	b81a2d64d0	Pin valkey/postgresql resources; harden runner token step ... The live valkey and postgresql StatefulSets had memory limits raised by hand (8Gi and 2Gi). A helm upgrade reverts those to the bitnami 192Mi preset, and valkey then OOMs loading its ~3.3GB dataset. Move the limits into role defaults so upgrades keep them. Generate the runner token with kubectl exec against the deployment after waiting for its rollout, with retries, instead of kubernetes.core.k8s_exec (the control plane's kubernetes python client is too old for it). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-06 13:05:10 -05:00
ClaudeandClaude Opus 5.5	0f1ed99dfc	Log real client IPs and enable Gitea Actions with a runner ... - Trust X-Forwarded-For from the pod network (10.244.0.0/16) via security.REVERSE_PROXY_TRUSTED_PROXIES / REVERSE_PROXY_LIMIT so Gitea logs the external client address instead of the ingress-nginx pod IP. - Set actions.ENABLED explicitly and deploy an instance-wide runner via the gitea/actions chart (release "gitea-actions", pinned to 0.1.2). The registration token is generated in-cluster and stored in a Secret on first run, so no token lives in git or the vault. - Fix the old actions.yaml, which reused the "gitea" release name and would have clobbered the main Gitea release. - Add a demo workflow (.gitea/workflows/demo.yaml). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-06 12:56:58 -05:00
eric	b9f615dcb3	Initial commit	2026-02-27 17:30:50 -05:00