25 lines
2.0 KiB
Markdown
25 lines
2.0 KiB
Markdown
# loops Helm chart
|
|
|
|
This chart owns the loops web and worker topology, its MySQL and Valkey
|
|
services, persistent claims, probes, and optional Traefik route. It expects
|
|
existing Kubernetes Secrets named by `runtimeSecret`, `mysql.authSecret`,
|
|
`valkey.authSecret`, and (when bucket bootstrap is enabled)
|
|
`s3BucketJob.secretName`. Never put their values in a public values file.
|
|
|
|
For this homelab, [cluster-specific values](https://code.brunner.ninja/feedc0de/homelab-gitops/src/branch/main/apps/loops/values.yaml)
|
|
select the existing PVC names, storage classes, domain and Secret names. A fresh
|
|
installation may choose different storage; migrating a live installation must
|
|
preserve its PVC UIDs and database contents.
|
|
|
|
```sh
|
|
helm repo add brunner.ninja https://brunner.ninja/charts
|
|
helm repo update brunner.ninja
|
|
helm upgrade --install loops brunner.ninja/loops --namespace loops --create-namespace --wait --timeout 20m
|
|
```
|
|
|
|
The chart and image are released together. The Git tag and image tag match the upstream Loops release (for example `v1.0.0-beta.15`), `Chart.yaml.appVersion` is that exact tag, and chart versions come from `git describe --tags --long`. A chart-only commit after a release tag therefore gets a unique version such as `1.0.0-beta.15-1-g<hash>`.
|
|
|
|
CI checks out the matching upstream release, applies `patches/loops-frontend.patch`, builds the upstream Dockerfile, verifies PHP 8.5.12+ and FFmpeg 9.0.2, publishes the image to `registry.brunner.ninja`, publishes the chart to the public `brunner.ninja/charts` repository, and promotes the chart version to `homelab-gitops`. The frontend fix is now built into the immutable image; it is not a hash-specific ConfigMap overlay. The backend and Following-feed patches remain chart-managed and must be reviewed against the next upstream release before updating `appVersion`.
|
|
|
|
Argo CD runs `php artisan migrate --force` as a sync hook after the database and configuration resources are ready, and before the application Deployments roll out. Application pods keep automatic migrations disabled to avoid concurrent migration runs.
|