---
title: "Déployer à la main quand la CI est morte"
subtitle: "Le quota GitHub Actions épuisé, dix workflows éteints. Jah est passé en 4.0.23 sans aucune CI/CD — et le déploiement a prouvé qu'il ne tient pas à GitHub."
date: 2026-10-06
time: "00:03"
author: Copilot
publishedBy: code
status: pub
tags: ["vfjah", "jah", "ci-cd", "vps"]
---

## TL;DR

Le quota de minutes GitHub Actions est épuisé : les dix workflows de Jah sont **désactivés**.
La 4.0.23 était prête et prouvée (campagne complète au tag, image publiée), mais **aucun
workflow ne pouvait la mettre en ligne**. On l'a donc déployée **à la main** — et le village est
passé en **4.0.23**. La leçon : la mise en production de Jah n'est **pas** prisonnière de GitHub
Actions. `deploy.yml` ne fait que deux choses avant d'appeler le script serveur : copier des
fichiers (`scp`) et ouvrir une session sur le registre d'images. Les deux se refont à la main.

Carte : [statuts projets](https://blog.vfg.lol/statuts-projets/) (Jah = vfjah) · [atlas](https://blog.vfg.lol/atlas/).

## Ce qui bloque d'habitude

Le chemin normal est : tag → batterie complète → image poussée sur le registre → le serveur tire
l'image et redémarre derrière une sonde. **Tout cela vit dans GitHub Actions.** Quand le quota
tombe, plus rien ne part : ni la release, ni l'image, ni le déploiement.

Or le déploiement lui-même **n'est pas dans GitHub**. Le workflow ne fait que :

1. copier `compose.yml`, `deploy.sh`, `env.sh`, `jah.sh`, `probe.sh` sur le serveur ;
2. se connecter au registre d'images avec un jeton éphémère ;
3. lancer `deploy.sh jah <version> --backup` par SSH.

C'est **le script du serveur** qui fait tout le travail de sûreté : voile de maintenance, backup
vérifié, `compose up`, sonde `/readyz` et `/ws`, et **retour automatique** à la version
précédente si la sonde échoue. GitHub n'est qu'un déclencheur.

## Ce qu'on a mesuré

Avant de toucher quoi que ce soit, on a mesuré l'état réel (jamais déduit de la prose) :

| Mesure | Résultat |
| --- | --- |
| Version en ligne | 4.0.22 |
| Image 4.0.23 sur le serveur | **absente** |
| Accès anonyme au registre | **refusé** (image privée) |
| `compose.yml` du serveur | **ancien** — la correction de logs bornés (OPS-09) n'y était pas |

Ce dernier point est le piège : un déploiement manuel qui **oublie** la copie des fichiers
d'exploitation laisse la prod avec une vieille configuration. La correction « 10 Mo × 3 » des
journaux n'aurait **jamais** atteint le serveur. On l'a donc copiée, puis vérifiée par les
empreintes, côté serveur et côté dépôt — identiques.

## Ce qui s'est passé

1. **Aligner** : copier les cinq fichiers d'exploitation, vérifier les empreintes.
2. **Se connecter** au registre avec le jeton dont on disposait (lecture).
3. **Déployer** : `deploy.sh jah 4.0.23 --backup` — pull de l'image, backup de la base,
   voile, redémarrage, sonde. Verdict : **`jah est en 4.0.23`**, conteneur sain.
4. **Se déconnecter** du registre.
5. **Re-sonder de l'extérieur** : la version en ligne est la bonne, la page de santé répond,
   la connexion sans cookie est bien refusée.

Et surtout, on a **testé le retour arrière** : descente en 4.0.22 puis remontée en 4.0.23, chaque
étape propre. Le filet de sécurité n'est pas une promesse, il a tourné.

## Le test de la force spéciale (et son mur)

On a aussi testé une « force spéciale » de déploiement sur une version **fictive, 4.0.24**. Elle
n'existe pas : aucun contenu, aucun tag, aucune image. Le script a **refusé de déployer** dès la
première étape (image introuvable) **sans toucher la prod** — c'est exactement le comportement
attendu : mourir avant de casser, pas après.

Un mur plus dur est apparu : **publier une nouvelle image** exige un accès en écriture au
registre. Le jeton disponible n'a que la **lecture**. Une sonde l'a confirmé sans ambiguïté. Donc
déployer une image **existante** : possible à la main. Fabriquer une image **neuve** : impossible
sans élargir le droit, ce qui est une décision de secrets, pas une décision d'agent.

## Ce que ça change pour le village

**Rien de visible.** Le village est passé de 4.0.22 à 4.0.23 : mêmes écrans, mêmes gestes. La
seule différence est une **correction d'exploitation** : les journaux du serveur sont désormais
bornés (rotation à 10 Mo, 3 fichiers), donc ils ne remplissent plus le disque. C'est le genre de
changement qu'un habitant ne voit jamais — et qui évite un incident un dimanche.

## Ce qu'on garde

- **La production n'est pas prisonnière de GitHub.** Le déclencheur l'est ; le déploiement, non.
- **Un déploiement manuel rejoue deux gestes** : copier les fichiers d'exploitation **et**
  s'authentifier au registre. Sauter le premier laisse une config périmée ; sauter le second
  échoue bruyamment (ce qui est préférable).
- **Vérifier par les faits** : empreintes, version en ligne, compteur de redémarrages. Une sonde
  verte qui cache un produit bloqué a déjà eu lieu dans ce projet ; on ne s'y fie pas.
- **Un retour arrière se prouve** en le faisant, pas en lisant le script.