# Gitea Helm chart

Чарт лежит в `.helm`.

Зависимости:

- `universal-chart` `0.1.9` для `gitea-ci-worker`
- статический `Deployment` для `gitea`, потому что файловый backup должен жить sidecar-ом в том же pod-е, где смонтирован RWO PVC
- `postgresql-preprod` `16.4.8` из `oci://cr.yandex/crp3ccidau046kdj8g9q/charts`

HTTP-маршрутизации здесь нет: ни `Ingress`, ни `VirtualService`. VS управляется отдельным чартом.

## Секреты

В `values.yaml` нет чувствительных значений. Чарт создает `gitea-secret` через `lookup`: если Secret уже существует, значения сохраняются; если нет, создаются сгенерированные заглушки. С заглушками runner и S3 backup не заработают, пока Secret не будет заполнен реальными данными.

Перед установкой можно создать Secret отдельно:

```bash
kubectl create namespace gitea --dry-run=client -o yaml | kubectl apply -f -

kubectl -n gitea create secret generic gitea-secret \
  --from-literal=runner-registration-token="$GITEA_RUNNER_REGISTRATION_TOKEN" \
  --from-literal=aws-access-key-id="$AWS_ACCESS_KEY_ID" \
  --from-literal=aws-secret-access-key="$AWS_SECRET_ACCESS_KEY" \
  --from-file=kubeconfig=./runner/kubeconfig/config \
  --from-file=docker-config.json=./runner/docker-config/config.json \
  --dry-run=client -o yaml | kubectl apply -f -
```

PostgreSQL пароль живет в `postgresql-secret`, который создает PostgreSQL chart и сохраняет через `helm.sh/resource-policy: keep`. Gitea читает ключ `user-password`.

## Установка

```bash
helm dependency update .helm
helm upgrade --install gitea .helm -n gitea --create-namespace
```

Если Secret создан уже после установки, перезапустить runner:

```bash
kubectl -n gitea rollout restart deploy/gitea-ci-worker
```

## Backup

Backup включен по умолчанию:

- `gitea-files-backup`: sidecar внутри pod `gitea`, каждый день в `02:30` архивирует `/data` и кладет в `s3://gitops-gitea/gitops-backups/gitea-files/`. Отдельного pod-а с mount PVC нет, поэтому не возникает second attach/Multi-Attach для `gitea-data`.
- `gitea-postgresql-backup`: каждый день в `02:45`, делает `pg_dump | gzip` и кладет в `s3://gitops-gitea/gitops-backups/postgresql/`

Оба backup-процесса используют S3-ключи из `gitea-secret`. Если там сгенерированные заглушки, backup завершится с понятной ошибкой и ничего не загрузит.

## Restore

Restore не включен в обычную установку. Это разовый Job, который включается отдельным values-файлом.

1. Взять имена объектов из S3:

```bash
aws --endpoint-url "$AWS_ENDPOINT_URL" s3 ls s3://gitops-gitea/gitops-backups/gitea-files/
aws --endpoint-url "$AWS_ENDPOINT_URL" s3 ls s3://gitops-gitea/gitops-backups/postgresql/
```

2. Скопировать `.helm/restore-values.example.yaml`, указать реальные `giteaFilesKey` и/или `postgresqlDumpKey`.

3. Запустить restore:

```bash
helm upgrade --install gitea .helm -n gitea -f restore-values.yaml
```

Режимы restore:

- полный restore: `restore.files.enabled=true` и `restore.postgresql.enabled=true`
- только файлы: `restore.files.enabled=true`, `restore.postgresql.enabled=false`
- только база: `restore.files.enabled=false`, `restore.postgresql.enabled=true`

Restore Job при `restore.scaleGitea.enabled=true` сначала масштабирует deployment `gitea` в `0` и ждёт удаления pod-а. Это нужно, чтобы restore файлов не монтировал RWO PVC одновременно с Gitea. После успешного completion отдельный `gitea-restore-scale-up` Job возвращает replicas обратно.