Gehostete Runnerreferenz auf GitHub

Hier findest du Informationen zu gehosteten Runnern in GitHub, einschließlich ihrer Spezifikationen und Anpassungsoptionen.

In diesem Artikel

Unterstützte Runner und Hardwareressourcen

Eine Reihe von GitHub-gehosteten Runnern steht in öffentlichen und privaten Repositories zur Verfügung.

Eine Liste der verfügbaren Runner finden Sie unter: * Standard-Runner für öffentliche Repositories

GitHub-gehostete Linux-Runner unterstützen die Hardwarebeschleunigung für Android SDK-Tools, wodurch die Ausführung von Android-Tests viel schneller wird und weniger Minuten in Anspruch nimmt. Weitere Informationen zur Android-Hardwarebeschleunigung finden Sie unter Konfigurieren der Hardwarebeschleunigung für den Android-Emulator in der Dokumentation für Android-Entwickler*innen.

Hinweis

Die -latest-Runner-Bilder sind die neuesten stabilen Bilder, die GitHub bereitstellt, und entsprechen möglicherweise nicht der neuesten Version des Betriebssystems, die beim Betriebssystemanbieter erhältlich ist.

Warnung

Beta- und veraltete Images werden „wie besehen“, „mit allen Fehlern“ und „wie verfügbar“ bereitgestellt und sind von der Servicelevelvereinbarung und der Garantie ausgeschlossen. Beta-Images werden möglicherweise nicht vom Kundendienst abgedeckt.

Standardmäßige GitHub-gehostete Runner für öffentliche Repositories

Für öffentliche Repositories werden Jobs, die die in der folgenden Tabelle aufgeführten Kennzeichnungen für Workflows verwenden, mit den entsprechenden Spezifikationen ausgeführt. Mit Ausnahme von Einzel-CPU-Läufern ist jeder von GitHub gehostete Runner eine neue virtuelle Maschine (VM), die von GitHub gehostet wird. Single-CPU Runner werden in einem Container auf einer freigegebenen VM gehostet – siehe Gehostete Runnerreferenz auf GitHub. Die Nutzung der standardmäßigen GitHub-gehosteten Runner ist für öffentliche Repositories frei und unbegrenzt.

Virtueller Computer/Container Prozessor (CPU) Speicher (RAM) Speicher (SSD) Architektur Workflow Bezeichnung
Linux 1 5 GB 14 GB x64 ubuntu-slim
Linux 4 16 GB 14 GB x64 ,
Windows 4 16 GB 14 GB x64 , , (öffentliche Vorschau),
Linux 4 16 GB 14 GB arm64 ,
Windows 4 16 GB 14 GB arm64 windows-11-arm
macOS 4 14 GB 14 GB Intel ,
macOS 3 (M1) 7 GB 14 GB arm64 , ,

Von GitHub gehostete Standard-Runner für private Repositorys

Für private Repositories werden Jobs, die die in der folgenden Tabelle aufgeführten Workflow-Kennzeichnungen verwenden, auf virtuellen Maschinen mit den entsprechenden Spezifikationen ausgeführt. Diese Runner verwenden das Kontingent Ihres GitHub Kontos für kostenlose Minuten und werden dann mit den Minutentarifen belastet. Weitere Informationen findest du unter AUTOTITLE.

Virtuelle Maschine Prozessor (CPU) Speicher (RAM) Speicher (SSD) Architektur Workflow Bezeichnung
Linux 1 5 GB 14 GB x64 ubuntu-slim
Linux 2 8 GB 14 GB x64 ,
Windows 2 8 GB 14 GB x64 ,
Linux 2 8 GB 14 GB arm64 ,
Windows 2 8 GB 14 GB arm64 windows-11-arm
macOS 4 14 GB 14 GB Intel ,
macOS 3 (M1) 7 GB 14 GB arm64 , ,

Workflowprotokolle listen den Runner auf, der zum Ausführen eines Auftrags verwendet wird. Weitere Informationen finden Sie unter Anzeigen des Ausführungsverlaufs eines Workflows.

Einschränkungen für arm64 macOS-Runner

  • Alle Aktionen, die von GitHub bereitgestellt werden, sind mit arm64 GitHub-gehosteten Runnern kompatibel. Communityaktionen sind jedoch möglicherweise nicht mit arm64 kompatibel und müssen zur Laufzeit manuell installiert werden.
  • Die geschachtelte Virtualisierung wird aufgrund der Einschränkung des Apples Virtualisierungs-Frameworks nicht unterstützt.
  • Netzwerkfunktionen wie private Azure-Netzwerke und das Zuweisen statischer IPs sind derzeit für macOS größere Runner nicht verfügbar.
  • Die arm64 macOS-Runner haben keine statische UUID/UDID zugewiesen, da Apple dieses Feature nicht unterstützt. Den Intel MacOS-Runnern wird jedoch eine statische UDID zugewiesen, insbesondere 4203018E-580F-C1B5-9525-B745CECA79EB. Wenn Sie den Build auf demselben Host erstellen und signieren, auf dem Sie ihn testen möchten, können Sie mit einem Entwicklungsbereitstellungsprofil signieren. Wenn Sie eine statische UDID benötigen, können Sie Intel-Runner verwenden und ihre UDID ihrem Apple-Entwicklerkonto hinzufügen.

Single-CPU Runner

Single-CPU-Runner, die auf GitHub gehostet werden, sind sowohl in öffentlichen als auch in privaten Repositories verfügbar. Diese Runner, die mit dem Workflow-Label ubuntu-slim angegeben wurden, bieten eine kostengünstige Option zum Ausführen leichter Operationen. Diese Art von Runner ist für Automatisierungsaufgaben, Problembearbeitung und kurze Aufgaben optimiert. Sie sind nicht für typische umfangreiche CI/CD-Builds geeignet.

          `ubuntu-slim` Runner führen Aktionen-Workflows in Ubuntu Linux in einem Container anstelle einer vollständigen VM-Instanz aus. Wenn der Auftrag beginnt, stellt GitHub automatisch einen neuen Container für diesen Auftrag bereit. Alle Schritte des Jobs werden im Container ausgeführt. Dies bietet die Möglichkeit, dass die Schritte des Jobs Informationen über das Dateisystem des Runners austauschen. Wenn der Auftrag abgeschlossen ist, wird der Container automatisch außer Betrieb gesetzt. Jeder Container stellt eine Isolierung auf Hypervisor-Ebene 2 bereit.

Hinweis

Der Container für ubuntu-slim Runner läuft im unprivilegierten Modus. Dies bedeutet, dass einige Vorgänge, die erhöhte Berechtigungen erfordern – wie das Einhängen von Dateisystemen, die Nutzung von Docker-in-Docker oder der Zugriff auf Kernel-Funktionen auf niedriger Ebene – nicht unterstützt werden.

Ein minimales Set an Tools wird auf dem ubuntu-slim Runner-Image installiert, geeignet für leichte Aufgaben. Ausführliche Informationen dazu, welche Software auf dem ubuntu-slim Image installiert ist, finden Sie in der README-Datei im actions/runner-images Repository.

Nutzungslimits

Single-CPU Läufer folgen dem gleichen Parallelitätsmodell wie andere GitHub-gehostete Standardläufer. Weitere Informationen findest du unter Actions-Grenzwerte. Die Parallelität für die Runner wird durch Ihren Plan bestimmt.

Der Job-Timeout für Single-CPU-Runner beträgt 15 Minuten. Wenn ein Auftrag dieses Limit erreicht, wird dieser beendet und schlägt fehl.

Größerer Runner

Kunden mit GitHub Team- und GitHub Enterprise Cloud-Plänen können aus einer Reihe von verwalteten Virtual Machines wählen, die mehr Ressourcen als die Standard-GitHub-gehosteten Runner haben. Diese Computer werden als „größere Runner“ bezeichnet. Sie bieten die folgenden erweiterten Funktionen:

  • mehr RAM, CPU und Speicherplatz auf dem Datenträger
  • Statische IP-Adressen
  • Privates Azure-Netzwerk
  • Die Möglichkeit zum Gruppieren von Runnern
  • Automatische Skalierung zur Unterstützung gleichzeitiger Workflows
  • GPU-gestützte Runner

Diese größere Runner werden von GitHub gehostet und verfügen über eine Vorinstallation der Runneranwendung und anderer Tools.

Weitere Informationen finden Sie unter Verwenden größerer Runner.

Administratorrechte

Die Linux- und macOS-VMs werden beide mit dem kennwortlosen Befehl sudo ausgeführt. Wenn Sie Befehle ausführen oder Tools installieren müssen, die höhere Berechtigungen als die des aktuellen Benutzers erfordern, können Sie sudo verwenden, ohne ein Kennwort angeben zu müssen. Weitere Informationen finden Sie unter dem Sudo-Handbuch.

Die virtuellen Windows-Maschinen sind so konfiguriert, dass sie als Administratoren laufen, wobei die Benutzerkonten-Steuerung (UAC) deaktiviert ist. Weitere Informationen finden Sie unter Arbeitsweise der Benutzerkontensteuerung in der Windows-Dokumentation.

IP-Adressen

Um eine Liste der IP-Adressbereiche abzurufen, die GitHub Actions für von GitHub gehostete Runner verwendet, können Sie die GitHub-REST-API verwenden. Weitere Informationen finden Sie im actions-Schlüssel in der Antwort des GET /meta-Endpunkts. Weitere Informationen finden Sie unter REST-API-Endpunkte für Metadaten.

Windows- und Ubuntu-Runner werden in Azure gehostet und weisen daher die gleichen IP-Adressbereiche wie Azure-Rechenzentren auf. macOS-Runner werden in der eigenen macOS-Cloud von GitHub gehostet.

Da es so viele IP-Adressbereiche für von GitHub gehostete Runner gibt, wird nicht empfohlen, diese als Positivlisten für Ihre internen Ressourcen zu verwenden. Stattdessen wird empfohlen, größerer Runners mit einem statischen IP-Adressbereich oder mit selbst gehosteten Runnern zu verwenden. Weitere Informationen findest du unter Verwenden größerer Runner oder Selbstgehosteten Runnern.

Die Liste der GitHub Actions-IP-Adressen, die von der API zurückgegeben werden, wird ein Mal pro Woche aktualisiert.

Kommunikationsanforderungen für GitHub-gehostete Runner

Ein GitHub-gehosteter Runner muss Verbindungen zu GitHub-eigenen Endpunkten herstellen, um wichtige Kommunikationsoperationen durchzuführen. Darüber hinaus erfordert Ihr Runner möglicherweise Zugriff auf zusätzliche Netzwerke, die Sie innerhalb einer Aktion angeben oder nutzen.

Um eine ordnungsgemäße Kommunikation für GitHub-gehostete Runner zwischen den Netzwerken innerhalb Ihrer Konfiguration zu gewährleisten, stellen Sie sicher, dass die folgende Kommunikation möglich ist.

Hinweis

Einige der aufgeführten Domänen werden mithilfe von CNAME-Einträgen konfiguriert. Für bestimmte Firewalls musst du Regeln möglicherweise rekursiv für alle CNAME-Einträge hinzufügen. Beachte, dass sich die CNAME-Einträge in Zukunft ändern können und dass nur die aufgeführten Domänen konstant bleiben.

Erforderlich für wesentliche Vorgänge:

Shell
github.com
api.github.com
*.actions.githubusercontent.com

          **Erforderlich für Downloadaktionen:**
Shell
codeload.github.com

          **Erforderlich für den Up- und Download von Auftragszusammenfassungen, Protokollen, Workflow-Artefakten und Caches:**
Shell
results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

          **Erforderlich für Runnerversionsupdates:**
Shell
objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

          **Erforderlich für das Abrufen von OIDC-Token:**
Shell
*.actions.githubusercontent.com

          **Erforderlich für das Herunterladen oder Veröffentlichen von Paketen oder Containern in GitHub-Paketen:**
Shell
*.pkg.github.com
pkg-containers.githubusercontent.com
ghcr.io

          **Benötigt für Git Large File Storage**
Shell
github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

Erforderlich für Aufträge für Dependabot updates

Shell
dependabot-actions.githubapp.com

          **Zum Herunterladen von Releaseressourcen erforderlich:**
Shell
release-assets.githubusercontent.com

          **Für VNet erforderlich:**
Shell
api.snapcraft.io

Dateisysteme

GitHub führt Aktionen und Shell-Befehle in bestimmten Verzeichnissen auf der virtuellen Maschine aus. Die Dateipfade auf virtuellen Maschinen sind nicht statisch. Verwenden Sie die Umgebungsvariablen, die GitHub bereitstellt, um Dateipfade für die Verzeichnisse home, workspace und workflow zu erstellen.

VerzeichnisUmgebungsvariableBESCHREIBUNG
homeHOMEEnthält benutzerbezogene Daten. In diesem Verzeichnis können sich beispielsweise die Anmeldeinformation aus einem Anmeldeversuch befinden.
workspaceGITHUB_WORKSPACEAktionen und Shell-Befehle werden in diesem Verzeichnis ausgeführt. Eine Aktion kann den Inhalt dieses Verzeichnisses ändern, auf den dann nachfolgende Aktionen zugreifen können.
workflow/event.jsonGITHUB_EVENT_PATHDie POST-Nutzdaten des Webhookereignisses, das den Workflow ausgelöst hat. GitHub schreibt dies bei jeder ausgeführten Aktion neu, sodass der Dateiinhalt zwischen den Aktionen isoliert wird.

Eine Liste der Umgebungsvariablen, die GitHub für jeden Workflow erstellt, finden Sie unter Speichern von Informationen in Variablen.

Docker-Container-Dateisystem

Aktionen, die in Docker-Containern ausgeführt werden, haben statische Verzeichnisse unter dem Pfad /github. Wir empfehlen jedoch dringend, die Standard-Umgebungsvariablen zu verwenden, um Dateipfade in Docker-Containern zu erstellen.

In GitHub ist das Pfadpräfix /github reserviert, und es werden drei Verzeichnisse für Aktionen erstellt.

  • /github/home
  •         `/github/workspace` - **Hinweis**: GitHub Actions müssen vom standardmäßigen Docker-Benutzer (Root) ausgeführt werden. Stelle sicher, dass dein Dockerfile nicht die `USER`-Anweisung festlegt, andernfalls kannst du nicht auf `GITHUB_WORKSPACE` zugreifen.
  • /github/workflow