Machines de runner

Les jobs Windows, macOS et self-hosted, sur des machines que vous enregistrez.

Certains jobs ne peuvent pas tourner sur le cluster. Un conteneur Windows a besoin du noyau NT et n'existe pas sur un hôte Linux, et macOS ne se conteneurise pas — pour windows-latest et macos-latest, il n'y a donc de pod nulle part. Vous enregistrez la machine, et la plateforme l'atteint en SSH.

Quand vous en avez besoin#

Un job dont les labels ne correspondent à aucune machine échoue aussitôt plutôt que de tourner au mauvais endroit, et son annotation dit ce qui manque : aucune machine pour cet OS, une machine en cours de drainage ou un label qu'aucune n'a. Le run échoue au lieu d'annoncer un succès pour un travail jamais construit.

Enregistrer une machine#

Allez dans Paramètres → Plateforme → Machines de runner et cliquez sur Enregistrer une machine. Vous déclarez ce qu'est la machine : adresse, le compte sous lequel la CI tournera, l'OS, l'architecture et le nombre de jobs qu'elle accepte à la fois.

À aucun moment on ne vous demande de clé privée. La plateforme génère une paire ed25519, chiffre la moitié privée au repos avec le même chiffrement que les secrets, et ne vous montre que la publique.

Installer la clé#

L'écran vous donne la commande correspondant à l'OS de cette machine, car la destination diffère réellement.

Sous Linux et macOS, l'endroit habituel :

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA… eqs-mac-mini-1' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Sous Windows, ce n'est pas cet endroit. Pour tout compte du groupe Administrators, OpenSSH lit un fichier commun à la machine et ignore totalement ~/.ssh/authorized_keys :

Add-Content -Path "$env:ProgramData\ssh\administrators_authorized_keys" -Value 'ssh-ed25519 AAAA… eqs-win-runner-1'
icacls "$env:ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

Tester la connexion#

Tester ouvre une session et demande à la machine ce qu'elle est. Un aller-retour répond à trois questions : SSH fonctionne, un shell POSIX est présent, et quelle machine c'est vraiment.

Une machine enregistrée sous le mauvais OS échoue au test et le dit. Ce n'est pas un problème de connexion, et c'est pire : le routage enverrait les jobs windows-latest vers une machine Linux, et chacun échouerait sur une commande absente, sans que rien ne renvoie à l'enregistrement.

Quand un test échoue, vous recevez la raison telle quelle — ssh: connect to host 10.0.0.42 port 22: Operation timed out — plutôt qu'une erreur générique. Une machine jamais jointe le dit, ce qui n'est pas la même chose qu'injoignable.

Ce qu'il faut sur la machine#

• Un serveur SSH et un compte non privilégié pour faire tourner la CI.
• Un shell POSIX. Sous Windows, c'est Git for Windows, avec son bash.exe défini comme DefaultShell d'OpenSSH — chaque step y passe.
• git et tar, que Git for Windows fournit déjà.

Rien d'autre. Le runtime Node dont les actions JavaScript ont besoin est déposé par la plateforme — compilé pour l'OS et l'architecture de cette machine — au premier job qui y tourne.

Drainer et retirer#

Drainer termine les jobs en cours et n'en accepte plus : l'état à utiliser avant de redémarrer ou de mettre à jour une machine. Retirer fait que la plateforme l'oublie.

L'isolation est plus faible qu'un conteneur#

Autant le dire franchement. Un job sur une machine enregistrée voit ce que le job précédent a laissé hors de son workspace : le répertoire personnel, /tmp, les paquets installés, l'état de n'importe quel démon. Un conteneur donne une racine neuve à chaque fois, pas ceci.

Ce qui est atténué : le compte n'a pas de privilèges, le workspace est propre à chaque job, et le nettoyage refuse tout chemin hors de la racine de travail. Utilisez une machine enregistrée pour du travail que vous feriez tourner sereinement sur une build box partagée.