Von GitHub-hosted runners zu runnerhut migrieren

Was GitHub-hosted runners gut macht

• Keine Konfiguration – nichts zu installieren, nichts zu vertrauen
• Die Abrechnung ist bereits auf Ihrer GitHub-Rechnung konsolidiert
• Native arm64 und größere Läufergrößen bei kostenpflichtigen Plänen
• Unterstützt durch GitHubs eigene Support- und Statusseite

Wo wir uns unterscheiden

• Ungefähr das Doppelte des Minutenpreises von runnerhut auf jedem Betriebssystem
• Keine ausschließliche EU-Residierung für Actions Compute, Cache und Logs – GitHub ist eine Microsoft-Tochtergesellschaft mit Hauptsitz in den USA
• Der Cache ist auf 10 GB pro Repository begrenzt und wird aggressiv entfernt
• Die Cache-Wiederherstellung ist gedrosselt – große Caches dauern oft Minuten
• Standardläufer verwenden eine gemeinsam genutzte vCPU mit Noisy-Neighbour-Varianz
• Der Docker-Layer-Cache muss selbst neu erstellt oder an eine Registrierung gesendet werden
• Keine arbeitsablaufübergreifende Cache-Freigabe und keine Cache-Analyse

Die Migration

Und die Migration zurück

Wir veröffentlichen dies, weil nach der Schließung von BuildJet die Frage „Was wäre, wenn Sie verschwinden?“ eine berechtigte Frage ist. Beim Verlassen handelt es sich um dieselbe einzelne Zeile, die Sie geändert haben, um anzukommen.

Checkliste

1. Installieren Sie die runnerhut GitHub App auf den Repositories, die Sie verschieben möchten
2. Ändern Sie zunächst die Nachläufe in einem Job und vergleichen Sie die Zeiten mit denen des alten Läufers
3. Fügen Sie runner.arch zu den Cache-Schlüsseln hinzu, wenn Sie auch zu arm64 wechseln
4. Führen Sie den Rollout auf den Rest des Repositorys durch, sobald der Vergleich richtig aussieht
5. Legen Sie eine Budgetobergrenze und die Aufhebung der Parallelität fest, bevor Sie organisationsweit vorgehen