Runner auto-hébergé

Un runner auto-hébergé est un petit agent, subaya-runner, qui exécute les builds Subaya sur une machine que vous contrôlez plutôt que dans le cloud Subaya. Utilisez-le lorsque la chaîne d’outils est déjà installée sur cette machine — par exemple une installation Quartus sous licence — ou lorsque le build doit avoir lieu sur votre propre matériel.

Le runner se connecte en sortie à Subaya via un WebSocket sécurisé. Il n’a besoin d’aucun port entrant, d’aucun VPN ni d’aucune IP publique. Subaya lui envoie les builds par cette connexion.

Un runner exécute des builds pour sa propre organisation, avec des commandes que la plateforme a dérivées du projet de cette organisation. Un build s’exécute avec les privilèges du runner sur une machine qui vous appartient — le même modèle de confiance qu’un runner GitHub auto-hébergé. Ce n’est pas un bac à sable.

Prérequis

• Linux sur x86_64. D’autres plateformes suivront.
• HTTPS sortant (port 443) vers subaya-dev.com.
• Les outils nécessaires à vos builds, installés et présents dans le PATH de l’utilisateur qui exécute le runner. Le runner signale ce qu’il trouve ; il n’installe rien.
• Facultatif : Docker ou Podman, pour les builds dont la recette désigne une image de conteneur.

Installation

Dans la console, ouvrez Settings → Runners et choisissez Add runner. Donnez un nom au runner : Subaya affiche trois commandes dans lesquelles un jeton d’enrôlement à usage unique est déjà renseigné. Le jeton fonctionne une seule fois et expire au bout d’une heure.

Téléchargez et décompressez le runner :

curl -fsSL -o subaya-runner.tar.gz https://subaya-dev.com/cli/runner/latest/subaya-runner_linux_amd64.tar.gz && tar xzf subaya-runner.tar.gz

Configurez-le. Cette étape échange le jeton d’enrôlement contre les identifiants propres du runner et génère une paire de clés qui ne quitte jamais la machine :

./subaya-runner configure --url https://subaya-dev.com --token srt_... --name 'lab-quartus-01'

Exécutez-le au premier plan :

./subaya-runner run

Pour qu’il continue de tourner après un redémarrage, installez-le plutôt comme service systemd :

./subaya-runner install-service

Lancé avec votre propre utilisateur, cela installe un service utilisateur systemd ; lancé en root, un service système. Un service utilisateur s’arrête à la déconnexion, sauf si le lingering est activé pour votre compte :

sudo loginctl enable-linger "$USER"

En quelques secondes, le runner apparaît online dans Settings → Runners, avec les outils et versions qu’il a détectés.

Lui envoyer un build

Ciblez un runner par son nom avec --runner :

suya build <app> --source . --runner lab-quartus-01 --wait

Avant d’accepter le build, Subaya vérifie que le runner a signalé chaque outil nécessaire. Si le runner est hors ligne, le build attend dans la file et démarre dès que le runner se reconnecte.

Ce qui est enregistré

Au démarrage d’un build, le runner signale la chaîne d’outils exacte qu’il a mesurée : pour chaque outil, la chaîne de version, le chemin et le SHA-256 du binaire. C’est cette chaîne d’outils mesurée — et non celle demandée par le projet — que l’exécution enregistre.

Si le projet fixe explicitement une version d’outil (par exemple avec suya tools set quartus-pro 26.1.1) et que la version installée sur le runner ne correspond pas, le build est refusé et échoue avec toolchain_pin_mismatch. Rien n’est exécuté. Sans version fixée explicitement, c’est la version installée sur le runner qui est utilisée.

Révoquer un runner

Dans Settings → Runners, choisissez Revoke sur le runner. La révocation prend effet immédiatement : les identifiants du runner cessent de fonctionner, sa connexion est fermée, aucun autre build ne lui est envoyé et un build en cours échoue. La révocation est irréversible — pour réutiliser la machine, ajoutez-la comme nouveau runner et exécutez ./subaya-runner configure --replace avec le nouveau jeton.

Pour retirer également le service de la machine :

./subaya-runner uninstall-service

Dépannage

Le runner apparaît hors ligne. Vérifiez que le processus ou le service tourne et que la machine peut joindre subaya-dev.com sur le port 443 :

./subaya-runner status

Le runner se reconnecte seul après une perte réseau. Un build en cours au moment de la coupure échoue avec runner_disconnected ; relancez-le.

Le runner s’arrête avec « upgrade required ». Le runner est plus ancien que la version minimale acceptée par Subaya. Téléchargez la dernière version avec la commande ci-dessus, remplacez le binaire et relancez-le. Sa configuration est conservée.

Le build est rejeté avec 422 runner_missing_tool. Le runner n’a pas signalé un outil nécessaire au build. Installez l’outil, assurez-vous qu’il est dans le PATH du runner, puis redémarrez le runner pour qu’il signale à nouveau sa chaîne d’outils. L’erreur nomme l’outil manquant.

Le jeton d’enrôlement est refusé. Les jetons sont à usage unique et expirent au bout d’une heure. Créez-en un nouveau avec Add runner.

Étapes suivantes

• Espaces de travail et projets — où vivent les builds.
• Facturation et utilisation — comment le calcul cloud est mesuré.