Publication et canaux

Le gestionnaire de runners télécharge ce qu'il installe : l'exécutable du runner et son environnement Python. Ces fichiers sont déposés par la chaîne de publication, un dépôt par canal.

Ce qui est publié

Fichier	Rôle
Fluhoms-macos-arm64.zip	Le gestionnaire, application macOS
Fluhoms-win-x64.exe	Le gestionnaire, application Windows
fluhoms-linux-x64, fluhoms-linux-arm64	Le gestionnaire, ligne de commande seule
fluhoms_runner-<plateforme>	L'exécutable du runner, posé à l'installation
fluhoms-python.<plateforme>.tar.gz	L'environnement Python dédié (~160 Mo)
version.<plateforme>.json	La version publiée, comparée à celle installée

Les installeurs d'origine (FluhomsRunner-Installer.pkg, FluhomsRunner-Setup.exe, scripts Linux) restent publiés le temps que le gestionnaire remplace complètement l'ancien chemin.

Un dépôt par canal

Le canal est déterminé par le tag qui déclenche la publication :

Tag	Canal	Dépôt
fluhoms/runner/v1.2.3	prod	fluhoms-pub-prod
fluhoms/runner/v1.2.3-beta.4	beta	fluhoms-pub-beta
fluhoms/runner/v1.2.3-preprod.5	preprod	fluhoms-pub-preprod

Les noms de fichiers sont identiques d'un canal à l'autre : c'est le dépôt qui les sépare. Un lien de téléchargement ne diffère donc que par sa base, ce qui évite d'avoir à composer des noms différents selon l'environnement.

Chaque exécutable embarque son canal : la chaîne compile dedans l'adresse de la plateforme et celle du dépôt de mises à jour. Un runner de preprod se met à jour depuis preprod, sans configuration.

note

Les adresses proposées au téléchargement viennent du serveur, qui sait sur quel canal il tourne — et non d'une configuration du navigateur, qui pourrait diverger. Le portail vérifie de surcroît que chaque fichier existe avant de le proposer, plutôt que de renvoyer une erreur de stockage à qui clique.

Rejouer un déploiement en local

Rien n'est déposé tant qu'une version n'a pas été taguée : le chemin complet — portail, téléchargement, installation — resterait donc invérifiable avant une release. Or c'est là que les erreurs de nom de fichier ou de dépôt se paient le plus cher, puisqu'on ne les découvre qu'une fois publiées.

Un script rejoue cette publication sur le MinIO du compose de développement.

Publier

cd apps/fluhoms_launcher
bash scripts/publish-local.sh                # runner, gestionnaire, ligne de commande
bash scripts/publish-local.sh --with-python  # avec l'environnement Python

Les fichiers sont déposés sous les mêmes noms que la chaîne réelle, dans un dépôt fluhoms-pub-dev lisible sans identifiants. L'environnement Python est mis en cache localement : il n'est téléchargé qu'une fois.

Le script suppose que le compose de développement tourne (pnpm server:dev).

Servir ces fichiers

Deux réglages, selon ce que l'on veut éprouver :

Où	Variable	Effet
apps/fluhoms_server/.env	PUBLIC_DOWNLOAD_URL	Le lien remis au navigateur
apps/fluhoms_server/.env	INTERNAL_DOWNLOAD_URL	L'adresse par laquelle le serveur vérifie
Environnement du gestionnaire	FLUHOMS_DOWNLOAD_URL	L'installation les télécharge

# apps/fluhoms_server/.env
PUBLIC_DOWNLOAD_URL=http://localhost:9900/fluhoms-pub-dev
INTERNAL_DOWNLOAD_URL=http://minio:9000/fluhoms-pub-dev

caution

Les deux adresses diffèrent en développement, et les deux sont nécessaires.

Le serveur tourne en conteneur : « localhost » y désigne le conteneur lui-même, et non la machine qui héberge le dépôt. Sans l'adresse interne, sa vérification échoue et le portail annonce « bientôt » des fichiers pourtant publiés — le lien remis au navigateur, lui, serait pourtant valide.

En production les deux coïncident : l'adresse interne peut être omise.

export FLUHOMS_DOWNLOAD_URL=http://localhost:9900/fluhoms-pub-dev
fluhoms runner enroll mon-runner.dev.runnerfluhoms --path /tmp/essai

Le portail vérifiant la présence des fichiers, ses tuiles de téléchargement s'activent d'elles-mêmes une fois la publication faite — au plus tard cinq minutes après, le temps que sa vérification soit renouvelée.

Vérifier

curl -sI http://localhost:9900/fluhoms-pub-dev/Fluhoms-macos-arm64.zip | head -1
curl -s  http://localhost:9900/fluhoms-pub-dev/version.macos-arm64.json

Une installation menée à son terme laisse dans le dossier choisi l'exécutable du runner et un dossier python/ autoportant :

/tmp/essai/python/bin/python --version

Ce que chaque plateforme signe

Un binaire téléchargé est refusé, signalé ou accepté selon ce dont le système dispose pour l'authentifier. Les trois n'offrent pas les mêmes moyens.

Plateforme	Mécanisme	Sans lui
macOS	Developer ID + notarisation Apple	« Apple n'a pas pu confirmer… », ouverture refusée
Windows	Azure Code Signing, horodatage RFC 3161	SmartScreen barre le premier lancement
Linux	aucun mécanisme standard	rien ne distingue un binaire altéré

Sont signés : l'exécutable du runner et le gestionnaire, sur les deux plateformes qui le permettent. Le runner l'est avant sa publication et non seulement dans l'installeur : c'est ce binaire nu que le gestionnaire télécharge, et le signer plus tard laissait partir un fichier non signé.

La CI interrompt la publication si une signature ne se vérifie pas. Mieux vaut un tag qui échoue qu'un exécutable barré chez chaque client.

Empreintes

Chaque fichier publié est accompagné de son empreinte SHA-256, à la même adresse suffixée par .sha256 :

fluhoms_runner-linux-x64          fluhoms_runner-linux-x64.sha256
Fluhoms-macos-arm64.zip           Fluhoms-macos-arm64.zip.sha256
Fluhoms-win-x64.exe               Fluhoms-win-x64.exe.sha256
fluhoms-linux-x64                 fluhoms-linux-x64.sha256

Le gestionnaire la lit avant de télécharger, puis vérifie ce qu'il a reçu. Une empreinte qui ne correspond pas interrompt l'installation et efface le fichier : le laisser sur le disque reviendrait à l'exécuter au prochain démarrage.

L'environnement Python est vérifié avant extraction — une archive altérée déposerait des fichiers partout sous le dossier d'installation, autrement plus délicats à retirer qu'un refus immédiat.

Une garantie opportuniste, et c'est un choix

Une empreinte absente n'interrompt rien : les publications antérieures à cette vérification n'en sont pas accompagnées, et refuser une installation pour cette raison bloquerait plus qu'elle ne protégerait. La vérification ne devient une exigence qu'une fois tout le parc republié.

Pour vérifier à la main :

curl -sO https://<dépôt>/fluhoms-linux-x64
curl -s  https://<dépôt>/fluhoms-linux-x64.sha256
shasum -a 256 fluhoms-linux-x64

Signature et notarisation sous macOS

Trois barrières distinctes s'opposent à l'ouverture d'un gestionnaire téléchargé, et elles ne se manifestent pas par le même message.

Message affiché	Cause	Correctif
« … est endommagé et ne peut pas être ouvert »	Signature invalide : le paquet a été modifié après signature	Signer après avoir copié le runner dans le paquet
« Apple n'a pas pu confirmer que … ne contenait pas de logiciel malveillant »	Paquet signé mais non notarié	Notarisation et agrafage du billet
Aucun message, l'application ne s'ouvre pas	Instance déjà lancée retenant le verrou	Terminer le processus résiduel

L'ordre des opérations n'est pas indifférent. L'exécutable du runner voyage dans le paquet du gestionnaire ; l'y glisser après signature invalide l'ensemble. La chaîne de publication procède donc ainsi :

1. construction du paquet ;
2. copie du runner dans Contents/MacOS/ ;
3. codesign --force --options runtime --deep --timestamp ;
4. archivage, envoi à notarytool submit --wait ;
5. stapler staple sur le paquet, puis reconstruction de l'archive.

L'agrafage porte sur le paquet et non sur l'archive : sans lui, le système interroge Apple à chaque ouverture et refuse hors ligne. C'est pourquoi l'archive est reconstruite une fois le billet agrafé.

En publication locale

scripts/publish-local.sh signe avec une identité éphémère (--sign -) et ne notarise pas : il n'y a ni certificat Developer ID ni compte Apple en jeu. Un gestionnaire récupéré depuis le dépôt local reste donc bloqué par la quarantaine. Pour l'essayer :

xattr -dr com.apple.quarantine ~/Downloads/"Fluhoms Launcher.app"

Cette manipulation ne concerne que les essais locaux ; les binaires publiés par l'intégration continue sont notariés et s'ouvrent sans elle.

Le script scripts/install-local.sh enchaîne tout le parcours — téléchargement depuis le dépôt local, vérification de la signature, levée de la quarantaine, installation puis ouverture :

cd apps/fluhoms_launcher
./scripts/install-local.sh              # vers /Applications
./scripts/install-local.sh ~/Essais     # ou ailleurs

C'est la manière fidèle d'éprouver ce que vivra l'utilisateur : elle passe par l'archive publiée plutôt que par le paquet construit, et révèle donc les défauts que l'ouverture directe masque — un exécutable oublié, une signature rompue par une copie tardive, une archive périmée.

Sous macOS 15 et suivants, le contournement par clic droit n'existe plus pour une application en quarantaine : il faut passer par Réglages Système › Confidentialité et sécurité › Ouvrir quand même, ou lever l'attribut.