Sommaire
Scénarios douloureux : quand Jira et le Mac partagé se mordent
Le premier piège est l’illusion du déclencheur unique : Automation, webhooks et GitHub Actions écoutent la même issue ; deux événements proches (champ + transition) envoient deux charges utiles et le Mac lance deux xcodebuild concurrents. Le second piège est SSH comme bus général : même utilisateur OS pour humain et script Jira — un kill ou un redémarrage d’agent coupe l’autre. Le troisième est la file sans borne : timeouts HTTP Jira, retries Automation, amplification de bruit.
Documentez si Jira est source de lancement ou miroir de statut ; sans états intermédiaires (« en file », « nœud A », « terminé »), les commentaires deviennent le journal d’erreur. Pour la CI, une seule écriture par workspace : routage labels GHA et merge queue / concurrence. Pour le transport, le guide SSH vs VNC : session graphique et automation ne tolèrent pas la même surcharge — séparez pools ou créneaux avant d’optimiser les YAML.
Isolation des permissions : SSH, comptes et séparation automation / humain
Isolez par identités OS (homes et trousseaux séparés), clés SSH dédiées et authorized_keys restreint (forced command / bastion). Ne réutilisez pas la même clé pour scp manuel et webhook : rotation et audit s’effondrent. Matrice Ansible SSH / forks pour certificats et charges sans couper la collaboration.
Caches partagés (CocoaPods, Gradle, npm) : moindre privilège, pas de 0777 durable. Chemins mutables (DerivedData, /tmp/build-*) par build_id — build partagé SSH/VNC et permissions. Passerelle HTTP avant SSH : rate limit et sessions pour ne pas saturer launchd.
Champs Jira Automation, déclenchement et idempotence
Une rule Automation saine porte sur un ensemble minimal de champs : par exemple labels contenant ci:ios, un champ personnalisé Build ref (branche ou SHA court), et éventuellement priority pour la file. Évitez de déclencher sur « tout commentaire » si le corps n’est pas structuré : préférez un préfixe machine (/build ios release) ou un bouton Proforma qui écrit un champ dédié. Chaque payload vers votre orchestrateur doit inclure issue.key, l’identifiant de rule, un horodatage et un nonce ou hash des champs déclencheurs.
Idempotence : le récepteur conserve la dernière empreinte acceptée par couple (issue, cible de build) pendant une fenêtre (TTL 24–72 h selon fréquence). Les rejets « doublon » renvoient HTTP 200 avec un corps JSON stable pour que Jira ne considère pas l’appel comme échec permanent. Si vous chaînez Jira → GitHub repository_dispatch, réutilisez le même identifiant côté Actions pour corréler les logs. Pour worktrees et lockfiles côté Git, la matrice Git worktree et verrous complète ce schéma.
Tableau : étiquettes → nœud, verrou, file et timeouts
Les valeurs ci-dessous sont des points de départ pour une équipe de ~5–15 personnes sur deux nœuds Mac ; ajustez après mesure de la latence médiane en file et du taux d’échec flock.
| Étiquette / signal Jira | Routage nœud | Implémentation du verrou | flock / plafond file | Timeout job / backoff |
|---|---|---|---|---|
ci:ios + transition « Ready for build » |
Pool mac-ios-* (hash issue % N) | Redis SET build:issue NX + TTL 2 h |
File globale ≤ 20 pending ; flock -w 180 sur cache Pods |
Job 60–90 min ; retry webhook Jira 3× exp. 2n min max 15 min |
ci:mac-silicon (archive lourde) |
Nœud mac-heavy-1 exclusif | Fichier /var/run/meshmac-heavy.lock + flock -n |
1 job lourd actif ; file ≤ 8 ; pas de parallèle sur signatures | Job 90–120 min ; backoff file 30 s → 5 min cap |
ci:pr-check (lint / tests rapides) |
Premier nœud disponible (score charge) | Verrou court par workspace flock sur .build-lock |
Jusqu’à 2 PR-checks légers ; flock -w 120 caches partagés |
Job 15–25 min ; retry HTTP orchestrateur 5× linéaire +10 s |
hotfix:codesign |
Nœud avec trousseau entreprise + file prioritaire | Sémaphore Redis signing:org valeur 1 |
File prioritaire ≤ 5 ; flock -w 300 trousseau / keychain session |
Job 30–45 min ; pas de retry auto sur échec signature (stop + alerte) |
manual:debug (humain + Jira) |
Nœud mac-interactive réservé | « Seat lock » TTL + heartbeat (cf. FAQ réservation) | File CI 0 sur ce nœud pendant lock ; flock caches désactivé ou local | Session 60–120 min renouvelable ; backoff réservation 15 min tampon |
Si l’Automation appelle un script SSH one-shot, évitez un timeout réseau plus court que l’enqueue : Jira affiche un faux échec. Préférez ack immédiat puis mise à jour Jira (REST) quand le worker a fini.
FAQ : conflits entre orchestrateurs, files et utilisateurs
Q : Jira dit « succès » mais aucun binaire n’apparaît. Vérifiez d’abord que le webhook n’a pas uniquement validé l’enqueue : exigez une écriture de champ « Build run id » ou un commentaire machine avec lien vers les logs. Sinon l’équipe confond acquittement réseau et fin de pipeline.
Q : Deux étiquettes ci:ios et ci:mac-silicon sur la même issue déclenchent deux fois. Normalisez avec une rule unique « any label in set » + condition « label absent ci:queued » puis posez ce garde-fou avant l’appel HTTP. Côté serveur, l’empreinte idempotente doit inclure le set d’étiquettes trié, pas seulement la première.
Q : La file Redis grandit pendant une panne disque. Coupez l’entrée : seuil dur (refus avec message « pool saturé »), alerte, et bascule vers nœud secondaire si disponible — voir aussi la FAQ pool, quotas et conflits. Ne laissez pas Jira retenter indéfiniment sur une infrastructure déjà en détresse.
Q : Latence VPN rend la collaboration SSH pénible pendant les builds. Traitez la latence comme contrainte de conception : keepalives SSH, multiplexage maîtrisé, et séparation des gros artefacts (rsync/NFS) des sessions interactives — la FAQ stabilité, latence et SLA détaille les seuils utiles.
Synthèse et achat
En résumé : un couloir par classe de ressource (interactif, lourd, PR rapide), des verrous explicites (Redis ou flock local fiable), des plafonds de file visibles, et idempotence sur les mêmes champs Jira que vous affichez au métier. Mesurez avant d’ajouter des nœuds : si les conflits sont architecturaux, la multiplication des Mac sans règles reproduit le chaos plus vite.
Pour louer un Mac distant et isoler un nœud « heavy » ou « interactif » sans engagement de compte sur les pages vitrine, consultez les offres Meshmac (parcours public), le centre d’aide, l’accueil et la liste du blog. Ajouter un second nœud réduit souvent plus la contention Jira qu’un algorithme de file plus « intelligent » sur une seule machine saturée.
Passez de Jira à des builds Mac sans chaos de file
Enchaînez avec la FAQ flock, la matrice GitHub Actions et la FAQ réservation de places. Les boutons ci-dessous ouvrent des contenus consultables sans connexion.