# Rollback — Retour vers la chart officielle GitHub

Ce document couvre le retour de la source ArgoCD depuis ce fork Gitea
(`homegit.gyozamancave.fr/billisdead/postiz-helmchart`) vers la chart officielle
(`github.com/gitroomhq/postiz-helmchart`).

---

## Contexte de référence

| Paramètre | Fork Gitea (actuel) | Chart officielle (cible rollback) |
|---|---|---|
| `repoURL` | `https://homegit.gyozamancave.fr/billisdead/postiz-helmchart` | `https://github.com/gitroomhq/postiz-helmchart` |
| `targetRevision` | `main` | `HEAD` |
| `path` | `charts/postiz` | `charts/postiz` |

Les `values` inline dans l'Application ArgoCD ne changent pas.

---

## Scénario 1 — Rollback normal (ArgoCD accessible)

```bash
kubectl patch application postiz -n argocd --type='json' -p='[
  {"op": "replace", "path": "/spec/source/repoURL",        "value": "https://github.com/gitroomhq/postiz-helmchart"},
  {"op": "replace", "path": "/spec/source/targetRevision", "value": "HEAD"}
]'

kubectl annotate application postiz -n argocd \
  argocd.argoproj.io/refresh=hard --overwrite
```

Vérification :

```bash
kubectl get application postiz -n argocd \
  -o jsonpath='{"sync: "}{.status.sync.status}{"\nhealth: "}{.status.health.status}{"\nrevision: "}{.status.sync.revision}{"\n"}'
```

Résultat attendu : `sync: Synced`, `health: Healthy`, revision = dernier commit GitHub.

---

## Scénario 2 — Gitea inaccessible (rollback d'urgence)

Si `homegit.gyozamancave.fr` est down et qu'ArgoCD est bloqué en erreur de fetch,
appliquer le patch de la même façon — ArgoCD re-tentera depuis GitHub immédiatement.

```bash
# Même commande que le scénario 1 — ArgoCD abandonne le fetch Gitea dès que repoURL change
kubectl patch application postiz -n argocd --type='json' -p='[
  {"op": "replace", "path": "/spec/source/repoURL",        "value": "https://github.com/gitroomhq/postiz-helmchart"},
  {"op": "replace", "path": "/spec/source/targetRevision", "value": "HEAD"}
]'
```

Si ArgoCD lui-même ne répond plus, patcher le CRD directement via le control plane :

```bash
# Requiert un accès direct à k3s-master
KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl patch application postiz -n argocd \
  --type='json' -p='[
    {"op": "replace", "path": "/spec/source/repoURL",        "value": "https://github.com/gitroomhq/postiz-helmchart"},
    {"op": "replace", "path": "/spec/source/targetRevision", "value": "HEAD"}
  ]'
```

---

## Scénario 3 — Rollback après upgrade image (ex. v2.11.2 → v2.21.8 cassé)

Le rollback de la source chart ne suffit pas si l'image Postiz a aussi été changée
**et que Prisma a migré le schéma DB**. Dans ce cas, la séquence est :

### 3a. Rollback image seule (si DB non migrée)

Éditer les values inline de l'Application ArgoCD et remettre le tag d'origine :

```yaml
image:
  tag: "v2.11.2"
```

```bash
# Puis forcer le sync
kubectl annotate application postiz -n argocd \
  argocd.argoproj.io/refresh=hard --overwrite
```

### 3b. Rollback image + restauration DB (si Prisma a migré)

> **Toujours faire un `pg_dump` avant tout upgrade.**

```bash
# 1. Scale down pour éviter les écritures pendant la restauration
kubectl scale deployment postiz-postiz-app --replicas=0 -n default

# 2. Identifier le pod PostgreSQL
PGPOD=$(kubectl get pod -n default -l app.kubernetes.io/name=postgresql -o jsonpath='{.items[0].metadata.name}')

# 3. Vider le schéma (le dump pg_dump sans --clean ne contient pas de DROP TABLE)
kubectl exec -n default "$PGPOD" -- bash -c \
  'PGPASSWORD="<password>" psql -U postiz postiz -c \
  "DROP SCHEMA public CASCADE; CREATE SCHEMA public; \
   GRANT ALL ON SCHEMA public TO postiz; \
   GRANT ALL ON SCHEMA public TO public;"'

# 4. Restaurer depuis le backup local
kubectl exec -i -n default "$PGPOD" -- bash -c \
  'PGPASSWORD="<password>" psql -U postiz postiz' \
  < /path/to/postiz-backup-YYYYMMDD.sql

# 5. Remettre le tag image v2.11.2 dans les values ArgoCD, puis scale up
kubectl scale deployment postiz-postiz-app --replicas=1 -n default
```

---

## Scénario 4 — Rollback vers un commit Gitea précis (pas GitHub)

Si le problème vient d'un commit spécifique sur le fork mais que la branche `main`
reste valide, pointer sur le SHA du dernier commit stable :

```bash
# Trouver le SHA stable (ex. avant le commit problématique)
git -C /home/billisdead/gitea-trucs/postiz-helm log --oneline main | head -10

# Patcher vers ce SHA
kubectl patch application postiz -n argocd --type='json' -p='[
  {"op": "replace", "path": "/spec/source/targetRevision", "value": "<SHA>"}
]'
```

---

## Vérification post-rollback (tous scénarios)

```bash
# Source effective
kubectl get application postiz -n argocd \
  -o jsonpath='{.spec.source.repoURL}{"\n"}{.spec.source.targetRevision}{"\n"}'

# État de santé
kubectl get application postiz -n argocd \
  -o jsonpath='{"sync: "}{.status.sync.status}{"\nhealth: "}{.status.health.status}{"\n"}'

# Pod toujours Running sans restart
kubectl get pods -n default -l "app.kubernetes.io/name=postiz-app"

# Logs démarrage (vérifier absence d'erreur Temporal/DB/Redis)
kubectl logs -n default deployment/postiz-postiz-app --tail=30
```