README.md

# 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.
Package loops Kubernetes deployment 2026-10-22 17:39:25 +02:00			`# 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`
			```

Update Loops to security release beta.15 2026-10-26 06:53:10 +01:00			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.