V0.7.2 — Livraison continue

Publiée le 18/10/2026.

Documentation fonctionnelle

Ce que change la version pour les collaborateurs

Pourquoi

Depuis la 0.7.0, un Site Ubuntu s'installe sans le dépôt, mais les images arrivaient encore par docker save / docker load, et la mise à jour restait manuelle. Sans registre publié ni promotion d'un digest déjà vert, on ne pouvait ni poser un vrai Site qui se met à jour après une Release, ni refermer clairement l'isolement réseau des caméras (VLAN).

Ce qu'on peut faire maintenant

• Publier et tirer les quatre images du Site (api, web, pont, certificats) sur ghcr.io en multi-arch (amd64 + arm64), paquets publics — canal Staging :staging après CI verte sur main.
• Sur machine perso (Docker Desktop) : docker compose -f compose.yaml pull puis up -d --wait ouvre le Site sur https://localhost (joué ici avec ARGOS_VERSION=0.7.2, même digest que :staging au moment du test).
• À chaque Release vX.Y.Z, promouvoir le digest staging vers les étiquettes de version (X.Y.Z, :latest) — même digest, pas de rebuild ; les Sites prod suivent le semver.
• Installer un Site Ubuntu par installer-le-site.sh (docker compose pull) ; le Site répond en HTTPS.
• Mettre à jour au boot/restart de argos.service ou via mettre-a-jour-le-site.sh (artefact Release → /opt/argos, alignement ARGOS_VERSION, recreate ; codes 0 / 2 / 1).
• Lire le README (Hébergement Ubuntu + Essayer staging) : pull nominal, MAJ, secours save / load cohérents avec les scripts.
• Lire la procédure d'isolement VLAN (deux prises, caméras sans internet) — scénario de test humain 7 non rejoué sur cette passe (décision produit) ; voir #112.

Documentation technique

Spec versionnée : docs/specs/v0.7.2-livraison-continue.md

Issue parente : #107

V0.7.2 — Livraison continue

Problem Statement

Depuis la 0.7.0, un Site Ubuntu s'installe sans le dépôt, mais les images arrivent encore par docker save / docker load, et la mise à jour est manuelle. Le registre GitHub n'est pas publié. On ne peut pas poser un vrai Site qui se met à jour tout seul après une Release, ni promouvoir un digest déjà vert (testé en staging) vers la production sans rebuild. Le réseau des caméras isolé (VLAN, sans internet) est encore mal refermé côté documentation.

Solution

On publie les quatre images du Site (api, web, pont, certificats) sur ghcr.io, en multi-arch (amd64 + arm64), paquets publics.

Staging : dès qu'un SHA est sur main avec la CI tests verte, on pousse / retaggue ces digests vers l'étiquette :staging. Les développeurs (macOS ou Windows via Docker Desktop) et un Site Ubuntu de test peuvent les tirer pour valider.

Production : une GitHub Release vX.Y.Z promouvoit le digest staging vers les étiquettes de version (X.Y.Z, et éventuellement :latest pour usage manuel) — même digest, pas de rebuild. Les Sites Ubuntu de production suivent le semver des Releases (pas :latest).

Mise à jour d'un Site Ubuntu : au boot / restart de l'unité systemd, et via une commande unique, le Site détecte s'il existe une Release plus récente, met à jour les fichiers de /opt/argos (compose, scripts, …) depuis l'artefact de Release, aligne ARGOS_VERSION, tire les images, recreate Compose. Coupure courte du Live acceptée ; pas de timer quotidien (geste conscient, compatible avec l'enregistrement futur) ; pas de rollback automatique. L'install nominale utilise docker pull ; save / load reste un secours hors-ligne documenté brièvement.

VLAN : documentation claire de l'isolement (deux prises, caméras sans internet) en s'appuyant sur le macvlan déjà livré — pas de nouvel automatisme réseau.

User Stories

Publication et canaux

1. En tant que mainteneur, je veux que la CI construise et pousse les quatre images multi-arch vers ghcr quand main est vert, étiquetées :staging, pour qu'un digest testé soit disponible sans Release.
2. En tant que mainteneur, je veux qu'une GitHub Release vX.Y.Z retaggue le digest staging vers X.Y.Z (promotion), sans rebuild, pour que la prod reçoive exactement ce qui a été validé.
3. En tant que mainteneur, je veux pouvoir aussi pousser :latest à la Release pour un essai manuel, sans que les Sites prod s'y calent.
4. En tant qu'adopteur, je veux tirer les images sans jeton (paquets publics), pour installer un Site simplement.
5. En tant que développeur sur macOS ou Windows, je veux documenter comment tirer :staging avec Docker Desktop et le compose de prod, pour tester sans Ubuntu ni clone build obligatoire.

Install et mise à jour Ubuntu

6. En tant qu'installateur, je veux installer un Site Ubuntu en tirant les images depuis ghcr (docker pull), pour ne plus dépendre de save/load au nominal.
7. En tant qu'Administrateur, je veux qu'au démarrage (ou restart) du service argos, le Site cherche une Release plus récente et s'y mette à jour si besoin, pour ne pas laisser un Site figé sans geste.
8. En tant qu'Administrateur, je veux une commande unique qui détecte et applique une mise à jour si elle est possible (codes de sortie distincts : rien à faire / succès / échec), pour déclencher une MAJ sans attendre un reboot.
9. En tant qu'Administrateur, je veux que la mise à jour aligne ARGOS_VERSION sur le semver de la Release (ex. 0.7.2 → 0.7.3), pour savoir quelle version tourne.
10. En tant qu'Administrateur, je veux que la mise à jour rafraîchisse aussi compose et scripts dans /opt/argos depuis l'artefact de Release, pour ne pas rester avec un vieux compose et des images neuves.
11. En tant qu'Administrateur, je veux qu'une coupure courte du Live pendant le recreate soit acceptable et documentée, sans rolling ni fenêtre horaire dans cette version.
12. En tant qu'Administrateur, je veux qu'un échec de mise à jour soit journalisé sans rollback automatique, pour corriger à la main (y compris en remettant un ARGOS_VERSION précédent).
13. En tant qu'installateur hors ligne, je veux encore une courte procédure save/load en secours, pour le jour sans internet sur l'hôte.

Staging sur un Site de test

14. En tant que mainteneur, je veux pouvoir faire suivre :staging à un Site Ubuntu de test (via ARGOS_VERSION=staging ou équivalent documenté), pour valider avant la Release.

Réseau

15. En tant qu'Administrateur, je veux lire dans la doc comment isoler le réseau des caméras (VLAN / prise dédiée, sans internet) alors que l'hôte tire ghcr sur l'autre prise, pour poser un vrai Site en sécurité.

README

16. En tant qu'installateur, je veux que le README Hébergement Ubuntu décrive pull, MAJ auto au boot, commande unique, et le secours save/load.
17. En tant que développeur, je veux une section pour essayer staging sur machine perso (macOS / Windows, Docker).

Implementation Decisions

• Registre : ghcr.io/ulyssoulv/argos-\{api,web,pont,certificats\} ; paquets publics ; manifestes multi-arch amd64+arm64.
• Canal staging : étiquette :staging mise à jour automatiquement quand la CI tests est verte sur main (retag des digests construits pour ce SHA).
• Canal production : GitHub Release vX.Y.Z = promotion (retag staging → X.Y.Z) ; pas de rebuild à la Release. :latest optionnel à la même Release, non suivi par les Sites prod.
• Sites prod : comparent la version locale (ARGOS_VERSION) à la dernière Release GitHub semver ; pas de suivi de :latest.
• Déclencheurs de MAJ Site : ExecStartPre (ou équivalent) au boot/restart de argos.service + script/commande unique (détecte + applique). Pas de timer systemd quotidien.
• Contenu MAJ : artefact de Release (compose, scripts de détection, éventuelle unité) → /opt/argos (sans écraser .env / secrets / certificats fournis) puis docker compose pull + recreate.
• Install : installer-le-site.sh (ou successeur) s'appuie sur pull ; README garde save/load en secours.
• ADR 0010 : canaux staging/production par retag de digest (affine ADR 0009 : staging/prod ne sont plus seulement « Mac vs Ubuntu », ce sont des canaux d'images ; une seule branche main).
• Windows : doc Docker Desktop pour staging seulement — pas d'hébergement Windows type /opt/argos / systemd.
• Auth ghcr : aucune pour le pull public.
• Hors CI Sonar ; bugs #86 / #95 hors périmètre.

Testing Decisions

Un bon test vérifie un comportement observable (workflows, scripts, compose, doc), pas le détail d'un Dockerfile couche par couche.

Seams (prior art tests/scripts/) :

• Présence et forme des workflows (build/push staging, promotion à la Release) — assertions sur YAML / scripts appelés, comme test_workflow_argos_tests.py.
• Script de mise à jour : avec Release / filesystem factices (détection semver, écriture ARGOS_VERSION, copie artefact sans toucher .env), codes de sortie ; pas besoin d'un Ubuntu réel ni de ghcr en CI.
• Script d'installation : chemin pull documenté / exercé en préfixe factice ; régression sur ce qui ne doit pas être écrasé.
• docker compose config : toujours autonome avec ARGOS_VERSION.
• Tests humains : lire README (pull, commande MAJ, staging doc) ; si machine Ubuntu dispo, install pull + commande MAJ ; isolation VLAN en lecture guidée si pas de labo réseau.

Out of Scope

• Enregistrement des Flux (0.8.0).
• Mise à jour sans coupure (rolling / blue-green).
• Timer de MAJ périodique ; fenêtres horaires.
• Rollback automatique.
• Hébergement Windows produit (systemd / /opt/argos).
• Paquets ghcr privés ; jeton sur le Site.
• Nouvelle automatisation réseau au-delà de la doc VLAN + macvlan existant.
• Correction des bugs #86 et #95.
• Scanner Sonar dans Actions.

Changements apportés aux versions antérieures

Version	Élément	Avant	Après	À annoter
0.7.0	Transfert d'images Ubuntu	docker save / load nominal	docker pull nominal ; save/load en secours	v0.7.0, #96, README
0.7.0	Mise à jour Ubuntu	load + aligner ARGOS_VERSION + restart manuel	MAJ au boot/restart + commande unique (semver Release, artefact, pull)	v0.7.0, #96, README
0.7.0 / ADR 0009	Staging / production	Environnements Mac vs Ubuntu	Canaux d'images :staging et Releases vX.Y.Z (promotion digest)	v0.7.0, ADR 0009

Further Notes

• La Release GitHub reste créée par le cycle /crel / finaliser-la-version ; le workflow de promotion réagit à cet événement.
• Ne pas confondre le terme glossaire Image (réglages capteur ONVIF) avec les images du Site (conteneurs).