Überblick über von GitHub gehostete Runner
Runner sind die Computer, die Aufträge in einem GitHub Actions-Workflow ausführen. Beispielsweise kann ein Runner dein Repository lokal klonen, Testsoftware installieren und dann Befehle ausführen, die deinen Code auswerten.
GitHub stellt Runner bereit, mit denen du deine Aufträge ausführen kannst. Stattdessen kannst du auch eigene Runner hosten. Jeder von GitHub gehostete Runner ist eine neue VM, die von GitHub mithilfe der Runneranwendung sowie weiteren vorinstallierten Tools gehostet wird und unter Ubuntu Linux, Windows oder macOS-Betriebssystemen verfügbar ist. Wenn du einen GitHub-gehosteten Runner verwendest, werden Computerwartung und Upgrades für dich erledigt.
Verwenden eines von GitHub gehosteten Runners
Um einen von GitHub gehosteten Runner zu verwenden, musst du einen Auftrag erstellen und mithilfe von runs-on
den Typ von Runner angeben, der den Auftrag verarbeiten wird, z. B. ubuntu-latest
, windows-latest
oder macos-latest
. Eine vollständige Liste der Runnertypen findest du unter Informationen zu von GitHub gehostete Runnern.
Wenn der Auftrag beginnt, stellt GitHub automatisch eine neue VM für diesen Auftrag bereit. Alle Schritte eines Auftrags werden auf demselben Runner ausgeführt, damit die Aktionen in diesem Auftrag Informationen über das Dateisystem austauschen können. Du kannst Workflows direkt auf der VM oder in einem Docker-Container ausführen. Wenn der Auftrag abgeschlossen ist, wird die VM automatisch außer Betrieb genommen.
Das folgende Diagramm veranschaulicht, wie zwei Aufträge in einem Workflow auf zwei unterschiedlichen von GitHub gehosteten Runnern ausgeführt werden.
Der folgende Beispielworkflow weist zwei Aufträge namens Run-npm-on-Ubuntu
und Run-PSScriptAnalyzer-on-Windows
auf. Wenn dieser Workflow ausgelöst wird, stellt GitHub eine neue VM für jeden Auftrag bereit.
- Der Auftrag namens
Run-npm-on-Ubuntu
wird auf einer Linux-VM ausgeführt, da derruns-on:
-Wert des Auftragsubuntu-latest
lautet. - Der Auftrag namens
Run-PSScriptAnalyzer-on-Windows
wird auf einer Windows-VM ausgeführt, da derruns-on:
-Wert des Auftragswindows-latest
lautet.
name: Run commands on different operating systems
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
Run-npm-on-Ubuntu:
name: Run npm on Ubuntu
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm help
Run-PSScriptAnalyzer-on-Windows:
name: Run PSScriptAnalyzer on Windows
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Install PSScriptAnalyzer module
shell: pwsh
run: |
Set-PSRepository PSGallery -InstallationPolicy Trusted
Install-Module PSScriptAnalyzer -ErrorAction Stop
- name: Get list of rules
shell: pwsh
run: |
Get-ScriptAnalyzerRule
Während der Auftrag ausgeführt wird, können Protokolle und Ausgabe in der Benutzeroberfläche von GitHub angezeigt werden:
Die GitHub Actions Läufer-Anwendung ist Open Source. Du kannst im Runner-Repository mitwirken und Dateiprobleme einreichen.
Unterstützte Runner und Hardwareressourcen
Hinweis: GitHub bietet zudem größerer Runner, die in größeren Konfigurationen verfügbar sind. Weitere Informationen findest du unter Übersicht über größerer Runner.
Hardwarespezifikation für Windows- und Linux-VMs:
- CPU mit 2 Kernen (x86_64)
- 7 GB RAM
- 14 GB SSD-Speicher
Hardwarespezifikation für macOS-VMs:
- CPU mit 3 Kernen (x86_64)
- 14 GB RAM
- 14 GB SSD-Speicher
Runner-Image | YAML-Workflow-Kennzeichnung | Hinweise |
---|---|---|
Windows Server 2022 |
windows-latest oder windows-2022
|
Die windows-latest -Bezeichnung verwendet derzeit das Windows Server 2022-Runner-Image.
|
Windows Server 2019 |
windows-2019
|
|
Ubuntu 22.04 |
ubuntu-latest oder ubuntu-22.04
|
Die ubuntu-latest -Bezeichnung verwendet derzeit das Ubuntu 22.04-Runner-Image.
|
Ubuntu 20.04 |
ubuntu-20.04
|
|
Ubuntu 18.04 [veraltet] |
ubuntu-18.04
|
Migriere zu ubuntu-20.04 oder ubuntu-22.04 . Weitere Informationen findest du in diesem Blogbeitrag auf GitHub.
|
macOS Monterey 12 |
macos-latest , macos-12 , macos-latest-xl oder macos-12-xl
|
Die Workflowbezeichnungen macos-latest und macos-latest-xl verwenden derzeit das macOS 12-Runnerimage.
|
macOS Big Sur 11 |
macos-11
|
|
macOS Catalina 10.15 [veraltet] |
macos-10.15
|
Migriere zu macOS-11 oder macOS-12 . Weitere Informationen findest du in diesem Blogbeitrag auf GitHub.
|
Hinweis: Die -latest
-Runner-Images sind die neuesten stabilen Images, 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 gesehen“, „mit allen Mängeln“ und „wie verfügbar“ bereitgestellt und sind von der Vereinbarung zum Servicelevel und der Garantie ausgeschlossen. Beta-Images werden möglicherweise nicht vom Kundendienst abgedeckt.
Workflowprotokolle listen den Runner auf, der zum Ausführen eines Auftrags verwendet wird. Weitere Informationen findest du unter Anzeigen des Ausführungsverlaufs eines Workflows.
Unterstützte Software
Die Softwaretools, die in GitHub-gehosteten Runnern enthalten sind, werden wöchentlich aktualisiert. Der Updatevorgang dauert mehrere Tage, und die Liste der vorinstallierten Software im main
-Branch wird nach Abschluss der gesamten Bereitstellung aktualisiert.
Vorinstallierte Software
Workflowprotokolle enthalten einen Link zu den vorinstallierten Tools für den jeweiligen Runner. Um diese Informationen im Workflowprotokoll zu finden, erweitere den Abschnitt Set up job
. Erweiter unter diesem Abschnitt den Abschnitt Runner Image
. Der auf Included Software
folgende Link beschreibt die vorinstallierten Tools auf dem Runner, der den Workflow ausgeführt hat.
Weitere Informationen findest du unter Anzeigen des Ausführungsverlaufs eines Workflows.
Die Gesamtliste der enthaltenen Tools für jedes Runnerbetriebssystem findest du unter den folgenden Links:
- Ubuntu 22.04 LTS
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS (veraltet)
- Windows Server 2022
- Windows Server 2019
- macOS 12
- macOS 11
- macOS 10.15
GitHub-gehostete Runner enthalten zusätzlich zu den oben aufgeführten Paketen die standardmäßig integrierten Tools des Betriebssystems. Ubuntu- und macOS-Runner umfassen beispielsweise grep
, find
und which
sowie weitere Standardtools.
Du kannst auch eine Softwarestückliste (Software bill of materials, SBOM) für jeden Build der Windows- und Ubuntu-Runnerimages anzeigen. Weitere Informationen findest du unter .
Verwenden vorinstallierter Software
Es wird empfohlen, Aktionen zu verwenden, um mit der Software zu interagieren, die auf Runnern installiert ist. Dieser Ansatz hat mehrere Vorteile:
- In der Regel bieten Aktionen flexiblere Funktionen wie Versionsauswahl sowie die Möglichkeit, Argumente und Parameter zu übergeben.
- Dies stellt sicher, dass die in deinem Workflow verwendeten Toolversionen unabhängig von Softwareupdates gleich bleiben.
Wenn ein Tool vorhanden ist, das du anfordern möchtest, öffne ein Issue unter actions/runner-images. Dieses Repository enthält auch Ankündigungen zu allen wichtigen Softwareupdates auf Runnern.
Installieren zusätzlicher Software
Du kannst zusätzliche Software auf von GitHub gehosteten Runnern installieren. Weitere Informationen findest du unter Anpassen von auf GitHub gehosteten Runnern.
Cloudhosts, die von GitHub gehosteten Runnern genutzt werden
GitHub hostet Linux- und Windows-Runner auf den Standard_DS2_v2
-VMs in Microsoft Azure, auf denen die Runneranwendung von GitHub Actions installiert ist. Die Runner-Anwendung auf GitHub-gehosteten Runnern ist eine Fork-Kopie des Azure-Pipelines-Agenten. Bei Azure werden eingehende ICMP-Pakete werden für alle virtuellen Maschinen blockiert, so dass die Befehle ping und traceroute möglicherweise nicht funktionieren. Weitere Informationen zu den Standard_DS2_v2
-Ressourcen findest du in der Microsoft Azure-Dokumentation unter Dv2- und DSv2-Serie.
GitHub hostet macOS-Runner in der eigenen macOS-Cloud von GitHub.
Workflowkontinuität
Wenn GitHub Actions-Dienste vorübergehend nicht verfügbar sind, wird eine Workflowausführung verworfen, wenn sie nicht innerhalb von 30 Minuten nach dem Auslösen in die Warteschlange gestellt wurde. Wenn beispielsweise ein Workflow ausgelöst wird und die GitHub Actions-Dienste für 31 Minuten (oder länger) nicht verfügbar sind, wird die Workflowausführung nicht verarbeitet.
Wenn die Workflowausführung erfolgreich in die Warteschlange eingereiht wurde, aber nicht innerhalb von 45 Minuten von einem GitHub-gehosteten Läufer verarbeitet wurde, wird die Workflowausführung in der Warteschlange verworfen.
Administratorrechte
Die Linux- und macOS-VMs werden beide mit dem kennwortlosen Befehl sudo
ausgeführt. Wenn du Befehle ausführen oder Tools installieren musst, die höhere Berechtigungen als die des aktuellen Benutzers erfordern, kannst du sudo
verwenden, ohne ein Kennwort angeben zu müssen. Weitere Informationen findest du im Sudo-Leitfaden.
Die virtuellen Windows-Maschinen sind so konfiguriert, dass sie als Administratoren laufen, wobei die Benutzerkonten-Steuerung (UAC) deaktiviert ist. Weitere Informationen findest du unter Funktionsweise der Benutzerkontensteuerung in der Windows-Dokumentation.
IP-Adressen
Hinweis: Wenn du eine Positivliste mit IP-Adressen für dein Organisations- oder Unternehmenskonto auf GitHub verwendest, kannst du keine GitHub-gehosteten Runner verwenden, sondern benötigst stattdessen selbstgehostete Runner. Weitere Informationen findest du unter Informationen zu selbstgehosteten Runnern.
Um eine Liste der IP-Adressbereiche abzurufen, die GitHub Actions für von GitHub gehostete Runner verwendet, kannst du die GitHub-REST-API verwenden. Weitere Informationen findest du im actions
-Schlüssel in der Antwort des Endpunkts Meta.
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 deine internen Ressourcen zu verwenden.
Die Liste der GitHub Actions-IP-Adressen, die von der API zurückgegeben werden, wird ein Mal pro Woche aktualisiert.
Dateisysteme
GitHub führt Aktionen und Shell-Befehle in bestimmten Verzeichnissen auf der virtuellen Maschine aus. Die Dateipfade auf virtuellen Maschinen sind nicht statisch. Verwende die Umgebungsvariablen, die GitHub bereitstellt, um Dateipfade für die Verzeichnisse home
, workspace
und workflow
zu erstellen.
Verzeichnis | Umgebungsvariable | BESCHREIBUNG |
---|---|---|
home | HOME | Enthält benutzerbezogene Daten. In diesem Verzeichnis können sich beispielsweise die Anmeldeinformation aus einem Anmeldeversuch befinden. |
workspace | GITHUB_WORKSPACE | Aktionen 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.json | GITHUB_EVENT_PATH | Die 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, findest du unter 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 dieUSER
-Anweisung festlegt, andernfalls kannst du nicht aufGITHUB_WORKSPACE
zugreifen./github/workflow
Weitere Informationsquellen
- Abrechnung für GitHub Actions verwalten
- Du kannst deine Aufträge mithilfe einer Matrixstrategie auf mehreren Images ausführen. Weitere Informationen findest du unter Verwenden von Matrizen für deine Aufträge.