CI/CD avec GitHub Actions¶

AKKO embarque quatre workflows GitHub Actions qui transforment un simple git push sur main en pipeline complet build → push → deploy → test sur le serveur de production. Tous les workflows tournent sur des runners GitHub hébergés (plan Free, 2000 min/mois pour les repos privés) et sont gratuits.

Les quatre workflows¶

Workflow	Déclencheur	Durée	Rôle
Helm Lint	PR, push sur branche non-main	~3 min	`helm lint` + `helm template --debug` sur tous les sub-charts
Build Images	Push `main` (si `docker/`, `branding/`, `docs/` modifiés)	~15 min (parallèle)	Build des 16 images custom + push sur `ghcr.io/akko-p/akko-*:2026.04`
Deploy to Netcup	Push `main` (si `helm/` modifié) ou après Build Images	~10 min	SSH → `git pull` → `helm upgrade` → attendre rollouts
Post-Deploy Tests	Après Deploy réussi	~10 min	SSH → `tests/run-all.sh --fast` → build en échec si un test échoue

Cycle complet sur un merge PR typique : ~25 min end-to-end, 100% automatisé.

Setup initial¶

1. Secrets GitHub (Settings → Secrets and variables → Actions)¶

Ajouter trois secrets :

Nom	Valeur	Comment générer
`NETCUP_HOST`	IP publique ou hostname du serveur Netcup (ex: `159.195.77.208`)	Copier depuis le panneau Netcup
`NETCUP_USER`	Utilisateur SSH (ex: `root`)	Connu
`NETCUP_SSH_KEY`	Clé SSH privée ed25519 (contenu de `~/.ssh/github_actions_netcup`)	Voir étape 2

2. Générer une clé SSH dédiée pour GitHub Actions¶

Sur n'importe quelle machine avec accès SSH à Netcup :

# Générer une nouvelle paire (pas de passphrase — la CI ne peut pas déverrouiller interactivement)
ssh-keygen -t ed25519 -C "github-actions-akko" -f ~/.ssh/github_actions_netcup -N ''

# Copier la clé publique sur Netcup (ajoute à ~/.ssh/authorized_keys)
ssh-copy-id -i ~/.ssh/github_actions_netcup.pub root@159.195.77.208

# Vérifier
ssh -i ~/.ssh/github_actions_netcup root@159.195.77.208 "echo 'OK'"

Puis copier le contenu de la clé privée (fichier sans .pub) :

cat ~/.ssh/github_actions_netcup

Coller la totalité (avec les lignes -----BEGIN OPENSSH PRIVATE KEY----- / -----END OPENSSH PRIVATE KEY-----) dans le secret GitHub NETCUP_SSH_KEY.

3. Permissions GHCR (automatique)¶

Les images sont poussées vers ghcr.io/akko-p/akko-<name>. Le GITHUB_TOKEN intégré a le bon scope quand permissions: packages: write est déclaré dans le workflow (déjà fait dans build-images.yml).

Au premier push, les packages sont privés par défaut. Pour que le cluster puisse les puller :

Sur GitHub : https://github.com/orgs/AKKO-p/packages
Sélectionner un package (ex: akko-postgres)
Package settings → Manage Actions access → vérifier que ton repo a accès en Read.
Pour que le cluster Netcup puisse puller : créer un imagePullSecret (étape suivante).

4. Configurer Netcup pour puller depuis GHCR¶

Créer un Personal Access Token (classic) avec scope read:packages : https://github.com/settings/tokens/new?scopes=read:packages

Sur Netcup :

kubectl create secret docker-registry ghcr-auth -n akko \
  --docker-server=ghcr.io \
  --docker-username=<ton-username-github> \
  --docker-password=<ton-token-pat>

Référencer dans helm/examples/values-netcup.yaml :

global:
  image:
    registry: "ghcr.io/akko-p"
    pullSecrets:
      - name: ghcr-auth

Après un helm upgrade, tous les pods pullent depuis GHCR via le secret.

Enchaînement des workflows¶

graph LR
    A[Push main] --> B{Path modifié?}
    B -->|docker/* | branding/*| C[Build Images]
    B -->|helm/*| D[Deploy to Netcup]
    C --> D
    D --> E[Post-Deploy Tests]
    E --> F[GitHub Status ✅/❌]
    A2[PR ouverte] --> G[Helm Lint]
    G --> H[Merge OK / bloqué]

Déclenchement manuel¶

Tout workflow peut être déclenché manuellement depuis Actions → workflow → Run workflow :

Build Images : rebuild tout même sans modif de code (utile après un patch CVE)
Deploy to Netcup : dry_run: true pour prévisualiser helm template sans appliquer
Post-Deploy Tests : full: true pour lancer la suite complète 45 min au lieu de fast (10 min)

Rollback en cas d'échec¶

Si Deploy to Netcup ou Post-Deploy Tests échoue, la révision Helm précédente reste active (les upgrades Helm sont atomiques). Rollback manuel :

ssh root@159.195.77.208
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
helm history akko -n akko
helm rollback akko <révision-précédente> -n akko

Le rollback automatique sur échec de tests est une amélioration prévue (Plan prod-ready : repo privé akko-technical-map/roadmap/plan-prod-ready.md).

Coût & limites¶

Plan Free (repo privé) : - 2000 minutes CI / mois sur runners Linux - Stockage GHCR 500 MB gratuit, puis 0.25$/Go/mois (environ 2 Go stockés pour AKKO = ~0.50$/mois au pire, le plus souvent couvert par le tier gratuit) - Bande passante GHCR illimitée depuis GitHub Actions, 1 Go/jour sinon

Consommation mensuelle typique : - 20 pushes sur main × 25 min = 500 min (25% du quota) - Restant 1500 min pour PRs, runs manuels, retries

Aucune limite dure ne bloque l'usage prod.

Dépannage¶

`permission denied` lors du push GHCR¶

Vérifier que le workflow a permissions: packages: write. Déjà déclaré dans build-images.yml mais un workflow custom peut l'oublier.

`Host key verification failed` en SSH¶

Le ssh-keyscan a pu manquer l'hôte. Exécuter une fois manuellement depuis une machine de confiance :

ssh-keyscan -H 159.195.77.208 | base64

Stocker la sortie dans un nouveau secret NETCUP_KNOWN_HOSTS et l'injecter dans le workflow — bypass du keyscan dynamique.

`helm upgrade failed: cannot patch PVC`¶

Drift entre tailles PVC values-netcup.yaml et PVC réelles. Fix dans values-netcup.yaml et re-push (voir DEPLOYMENT.md Troubleshooting).

Tests en échec mais pods OK¶

Vérifier quel test a échoué dans l'artifact : https://github.com/AKKO-p/AKKO/actions → run → artifact tests-log- → télécharger → inspecter.