Document Gitea and Argo migration completion checks

This commit is contained in:
2026-10-19 17:17:48 +02:00
parent c61ddefe2a
commit fcee3b9929
+21 -2
View File
@@ -21,14 +21,33 @@ application/image version. CI derives the chart package version from Git:
- the next commit produces a unique version such as
`1.0.0-1-g41627abcdef`.
The shared chart repository uses per-chart tags such as
`wordcraft-v1.0.0`; a single-chart repository uses `v1.0.0`.
The target layout is one repository per maintained chart, with tags such as
`v1.0.0`. Existing shared repositories are legacy, not a template for new
charts.
The hash is retained to prevent package-version collisions. CI publishes to
`https://brunner.ninja/charts`, then uses `GITOPS_TOKEN` to update only the
matching Argo Application's exact Helm `targetRevision`. Argo CD performs the
deployment; chart CI never receives Kubernetes credentials.
## Migration completion check
For a maintained chart, keep the chart and CI in its own source repository.
Before activating a new Argo Application, publish the chart and verify its
exact version in the Gitea Helm index. It is safe to commit the Application,
AppProject, and values files first without listing the Application in
`bootstrap/kustomization.yaml`; this lets chart CI update its version without
creating an Argo Application that points to a missing chart. Activate it after
publication, then verify both `homelab-bootstrap` and the new Application are
Synced and Healthy.
If Gitea Actions fails, inspect the failed job's steps and logs before asking
for help or changing the workflow. On arschrock, Gitea's local admin CLI can
create scoped tokens for repository Actions secrets; see the workspace
`AGENTS.md` for the command, API path, and secret handling rules. Complete the
CI rerun, chart publication, GitOps promotion, Argo rollout, ready containers,
exact image tag, and PVC UID/volume check before declaring a migration done.
GitOps values may select namespaces, hostnames, ingress integration, existing
claims or storage classes/sizes, resource sizing, replica counts, monitoring
labels, and names of existing Secrets. They must not duplicate chart-owned