98 lines
3.9 KiB
YAML
98 lines
3.9 KiB
YAML
gitea:
|
|
# Adopting the standalone install from localvm-kubernetes-setup's
|
|
# deploy_gitea.sh (helm release "gitea", namespace "gitea") — same
|
|
# config, translated to values so it's GitOps-managed from here on.
|
|
# See devops-infra-argo-config values/admin/incubator-infra-k8s-admin-prd-ase1-values.yaml
|
|
# for the nameOverride that makes Argo's render match the existing
|
|
# release/object names instead of creating a second Gitea.
|
|
#
|
|
# sqlite + valkey/postgres disabled: sqlite is enough for a lab, and
|
|
# the valkey-cluster pod was stuck Pending until the StorageClass was
|
|
# fixed (claude.md issue #2/#3) — disabling it avoids that dependency.
|
|
# persistence.size must stay 10Gi to match the already-bound PVC —
|
|
# local-path-provisioner doesn't support volume expansion.
|
|
|
|
# Chart default is RollingUpdate with maxUnavailable: 0 — the new pod
|
|
# always comes up before the old one terminates. On a real multi-node
|
|
# cluster with real RWO block storage that's fine (the new pod just
|
|
# can't mount until the old one releases). On this single-node cluster,
|
|
# local-path-provisioner's hostPath-style volume doesn't block a second
|
|
# same-node mount, so old+new pods briefly run concurrently against the
|
|
# same /data — and Gitea's LevelDB-backed queue holds an exclusive file
|
|
# lock, so the new pod crashes with "unable to lock level db ...
|
|
# resource temporarily unavailable". Recreate forces the old pod to
|
|
# fully terminate (and release the lock) before the new one starts.
|
|
strategy:
|
|
type: Recreate
|
|
|
|
# Scopes Replace=true to ONLY the Deployment (not the whole Application —
|
|
# see the note in devops-infra-argo-config's values file for why that
|
|
# broke the PVC). The `configure-gitea` init container's
|
|
# GITEA_ADMIN_USERNAME/PASSWORD env vars still carry plaintext `value`
|
|
# fields on the live object from the original imperative install; ours
|
|
# switch those to `valueFrom: secretKeyRef` (below), and a patch can't
|
|
# clear the old field while adding the new one. A full PUT of just this
|
|
# one resource sidesteps that. Safe to remove once the live Deployment
|
|
# no longer carries the old `value` fields — after that first successful
|
|
# sync, plain patching is fine again.
|
|
deployment:
|
|
annotations:
|
|
argocd.argoproj.io/sync-options: Replace=true
|
|
|
|
persistence:
|
|
size: 10Gi
|
|
|
|
postgresql:
|
|
enabled: false
|
|
postgresql-ha:
|
|
enabled: false
|
|
valkey:
|
|
enabled: false
|
|
valkey-cluster:
|
|
enabled: false
|
|
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 300Mi
|
|
limits:
|
|
memory: 500Mi
|
|
|
|
gitea:
|
|
config:
|
|
database:
|
|
DB_TYPE: sqlite3
|
|
actions:
|
|
ENABLED: true
|
|
admin:
|
|
username: gitadmin
|
|
# The running install set this via a plaintext --set-string flag at
|
|
# install time. Correction from an earlier version of this comment:
|
|
# this is NOT install-time only — the `configure-gitea` init
|
|
# container re-runs GITEA_ADMIN_PASSWORD_MODE: keepUpdated on every
|
|
# pod (re)start, actively syncing the admin password from whatever
|
|
# this env var resolves to. That's what caused the value->valueFrom
|
|
# migration conflict fixed above — this Secret must exist and be
|
|
# correct before the Deployment syncs.
|
|
#
|
|
# As of the Vault + External Secrets Operator migration, this Secret
|
|
# is no longer manually kubectl-created — it's managed by the
|
|
# ExternalSecret at devops-infra-argo-config/secretstores/gitea-admin-credentials.yaml,
|
|
# sourced from Vault path secret/gitea/admin. Rotate the password via
|
|
# `vault kv put secret/gitea/admin ...`, not kubectl, from here on.
|
|
existingSecret: gitea-admin-credentials
|
|
email: "admin@local.lab"
|
|
|
|
ingress:
|
|
enabled: true
|
|
className: contour
|
|
hosts:
|
|
- host: gitea.192.168.1.7.nip.io
|
|
paths:
|
|
- path: /
|
|
pathType: Prefix
|
|
- host: gitea.100.90.248.118.nip.io
|
|
paths:
|
|
- path: /
|
|
pathType: Prefix
|