Les équipes multi-outils mutualisent souvent un Mac bare metal Apple Silicon entre GitLab CI et GitHub Actions ; la cohabitation tient si l'on traite quatre axes : quotas, labels, secrets et NVMe. Pour le cache et le disque côté Actions, voir 2026 — Multi-runners Mac auto-hébergés & CI parallèle : cache GitHub Actions, disque persistant, concurrence, disques pleins et nettoyage d'artefacts — FAQ pool d'entreprise ; pour la pression CPU et mémoire quand plusieurs workers Xcode tournent en parallèle sur un même hôte, voir 2026 — CI Mac d'entreprise : tests Xcode en parallèle et découpage des Test Plans — comment éviter la contention des simulateurs ? (nœuds haute mémoire, nombre de workers et seuils disque : FAQ).
1. Pourquoi partager un seul bare metal entre GitLab et GitHub ?
La motivation est presque toujours économique et opérationnelle : un seul nœud calibré pour les archives lourdes, les simulateurs et les outils de signature évite de dupliquer la RAM et le SSD NVMe. Le risque inverse est une contention invisible : deux orchestrateurs qui croient chacun « posséder » la machine. La règle d'architecture est simple : un budget global de slots (CPU, I/O, fenêtres simulateur) partagé entre les deux piles, publié et mesuré, plutôt que deux politiques indépendantes qui se gênent au moment des releases.
actions.runner comme deux clients d'une même file d'exécution locale, pas comme deux mondes ignorants l'un l'autre.2. Quotas de concurrence : aligner concurrent GitLab et la pression Actions
Le concurrent global de GitLab Runner borne les jobs parallèles ; côté GitHub Actions, la limite réelle est souvent CPU et disque. Fixez d'abord un plafond physique (par ex. deux xcodebuild archive max), puis des sous-quotas entre orchestrateurs. Surveillez le queue time par pile : si l'une monopolise les créneaux, baissez concurrent ou resserrez les labels avant d'acheter du matériel.
3. Routage par labels : contrat explicite entre dépôts et hôte
Les tags GitLab et labels GitHub routent vers le bon exécuteur. Sur hôte partagé, publiez une matrice versionnée (macos-15, m4-pro, etc.) et refusez les workflows sans filtre. Évitez self-hosted seul sur GitHub : ajoutez des labels d'équipe pour ne pas capter le même runner qu'un dépôt GitLab sensible.
4. Isolation des secrets : séparer les surfaces, pas seulement les dossiers
Séparez les jetons : pas de .env unique pour les deux services ; préférez plists launchd distincts ou un coffre (Vault, KMS) à politiques séparées. Sous macOS, des comptes distincts (gitlab-runner vs utilisateur Actions) limitent les collisions Trousseau et clarifient l'audit.
5. NVMe : comparer trois stratégies de cache pour la cohabitation
Les caches DerivedData, dépendances tierces et artefacts intermédiaires explosent vite quand deux orchestrateurs écrivent sur le même volume système. Le tableau suivant résume des approches observées sur le terrain ; adaptez les chemins à votre politique de sécurité.
| Stratégie | Avantages | Risques |
|---|---|---|
Un volume NVMe partagé avec préfixes par outil (gitlab/, gha/) |
Simplicité, une seule politique de sauvegarde | Courses d'écriture si les jobs partagent une même clé de cache |
Deux volumes APFS montés (/Volumes/gitlab-cache, /Volumes/gha-cache) |
Quota et nettoyage indépendants, erreurs plus localisées | Gestion double des snapshots et de l'espace libre |
| Cache distant (S3/MinIO) + NVMe local en tampon minimal | Moins de contention disque sur le Mac | Latence réseau ; modèle de cohérence à définir |
Fixez TTL/LRU et alertes d'espace libre avant les échecs en cascade.
6. FAQ synthétique
- Faut-il deux runners GitLab pour séparer les dépôts ? Souvent oui si les politiques de secrets diffèrent ; un seul runner multi-projets impose une discipline de tags stricte.
- GitHub « gagne » toujours la CPU ? Non en soi, mais les workflows matriciels volumineux peuvent saturer le disque ; imposez des plafonds par workflow.
- Peut-on mélanger jobs GUI et CLI sur ce même hôte ? Oui, en réservant des créneaux ou des labels dédiés pour éviter qu'un job interface ne bloque la fenêtre graphique pendant une archive critique GitLab.
- Comment valider le partage avant production ? Rejeu de traces réelles sur une fenêtre de charge avec les deux orchestrateurs actifs et mesure du P95 disque et du temps de file.
Apple Silicon, macOS et Mac mini : un banc d'essai réaliste pour la cohabitation
Les quotas et partitions NVMe n'ont de sens que si vos mesures reflètent la mémoire unifiée et le comportement disque réels d'Apple Silicon sous deux clients CI simultanés. macOS offre une pile stable pour xcodebuild, les simulateurs et les outils de signature, avec une surface de sécurité comprise par les équipes IT : Gatekeeper, SIP et FileVault réduisent fortement le risque par rapport à des postes Windows généralistes. Un Mac mini silencieux et sobre convient comme nœud de référence pour rejouer la charge mixte GitLab / GitHub avant de généraliser la configuration au pool.
Le Mac mini M4 combine performance, silence et faible consommation en veille (de l'ordre de quelques watts), ce qui facilite les campagnes de tests prolongées sans surcoût énergétique inutile. Si vous souhaitez aligner labo et production sur du matériel dédié dans le cloud, la page d'accueil Macstripe permet de choisir région et configuration — pour industrialiser la même recette que dans cet article, le Mac mini M4 reste aujourd'hui l'un des meilleurs compromis entre coût total de possession, stabilité et bande passante mémoire pour démarrer.
