Übersicht
Verwende jobs.<job_id>.runs-on zum Definieren des Computertyps, auf dem der Auftrag ausgeführt werden soll.
: Der Zielcomputer kann ein auf GitHub gehosteter Runner, ein größerer Runner oder ein selbstgehosteter Runner sein.
-
Du kannst Runner basierend auf den Bezeichnungen ausrichten, die ihnen zugewiesen sind, auf ihre Gruppenmitgliedschaft oder auf eine Kombination aus beiden.
-
Du kannst
runs-onals Folgendes angeben:- als einzelne Zeichenfolge
- als einzelne Variable, die eine Zeichenfolge enthält
- als ein Array von Zeichenfolgen, als Variablen, die Zeichenfolgen enthalten, oder als eine Kombination aus diesen beiden Optionen
- als ein
key: valuePaar, das die Tastengroupoderlabelsverwendet
-
Wenn du ein Array von Zeichenfolgen oder Variablen angibst, wird dein Workflow auf jedem Runner ausgeführt, der allen angegebenen
runs-on-Werten entspricht. Hier wird der Auftrag beispielsweise nur auf einem selbstgehosteten Runner mit den Bezeichnungenlinux,x64undgpuausgeführt:runs-on: [self-hosted, linux, x64, gpu]Weitere Informationen findest du unter Auswählen von selbstgehosteten Runnern.
-
Du kannst Zeichenfolgen und Variablen in einem Array mischen. Beispiel:
on: workflow_dispatch: inputs: chosen-os: required: true type: choice options: - Ubuntu - macOS jobs: test: runs-on: [self-hosted, "${{ inputs.chosen-os }}"] steps: - run: echo Hello world! -
Wenn du deinen Workflow auf mehreren Computern ausführen möchtest, verwende
jobs.<job_id>.strategy.
Hinweis
Anführungszeichen sind für einfache Zeichenfolgen wie z. B. self-hosted nicht erforderlich, werden aber für Ausdrücke wie "${{ inputs.chosen-os }}"
benötigt.
Auswählen von GitHub-gehosteten Runnern
Wenn du einen GitHub-gehosteten Runner verwendest, läuft jeder Job in einer neuen Instanz eines von runs-on angegebenen Runner-Images.
Der Wert für „wird ausgeführt auf“, wenn du einen GitHub-gehosteten Runner verwendest, ist eine Runnerbezeichnung oder der Name einer Runnergruppe. Die Bezeichnungen für die Standarddaten von GitHub-gehosteten Runnern werden in den folgenden Tabellen angezeigt.
Weitere Informationen finden Sie unter Von GitHub gehostete Runner.
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 |
|
Von GitHub gehostete Standard-Runner für interne und private Repositorys
Für interne und 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 Actions Runner Preise.
| 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 |
|
Hinweis
macOS-Runner sind nicht in Unterdomänen von GHE.com, z. B. in octocorp.ghe.com, verfügbar.
Neben den in GitHub gehosteten Standardrunnern bietet GitHub Kund*innen mit den GitHub Team- und GitHub Enterprise Cloud-Plänen eine Auswahl von verwalteten Virtual Machines mit erweiterten Funktionen, wie etwa: mehr Kerne und Datenträgerspeicherplatz, GPU-unterstützte Computer und ARM-unterstützte Computer. Weitere Informationen finden Sie unter Größere Läufer.
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 „as-is“, „with all faults“ und „as available“ bereitgestellt und von der Vereinbarung zum Servicelevel und der Garantie ausgeschlossen. Beta-Images werden möglicherweise nicht vom Kundendienst abgedeckt.
Beispiel: Angeben eines Betriebssystems
runs-on: ubuntu-latest
Weitere Informationen finden Sie unter Von GitHub gehostete Runner.
Auswählen von selbstgehosteten Runnern
Um einen selbstgehosteten Runner für deinen Auftrag anzugeben, konfiguriere runs-on in deiner Workflowdatei mit Bezeichnungen selbstgehosteter Runner.
Selbstgehostete Runner weisen möglicherweise die Bezeichnung self-hosted auf. Beim Einrichten eines selbstgehosteten Runners wird standardmäßig die Bezeichnung self-hosted eingeschlossen. Du kannst das Flag --no-default-labels übergeben, um zu verhindern, dass die selbstgehostete Bezeichnung angewendet wird. Mit Bezeichnungen können Optionen zur Zielgruppenadressierung für Runner erstellt werden, z. B. im Hinblick auf Betriebssystem oder Architektur. Wir empfehlen die Angabe eines Arrays von Bezeichnungen, das mit self-hosted beginnt (diese Bezeichnung muss als Erstes aufgeführt werden) und dann nach Bedarf weitere Bezeichnungen einschließt. Wenn du ein Array von Bezeichnungen angibst, werden Aufträge in die Warteschlange von Runnern eingereiht, die alle von dir angegebenen Bezeichnungen aufweisen.
Beachte, dass der Actions Runner Controller mehrfache Bezeichnungen nicht unterstützt und die Bezeichnung self-hosted nicht unterstützt.
Beispiel: Verwenden von Bezeichnungen für die Auswahl von Runnern
runs-on: [self-hosted, linux]
Weitere Informationen findest du unter Selbstgehosteten Runnern und Verwenden von selbstgehosteten Runnern in einem Workflow.
Auswählen von Runnern in einer Gruppe
Du kannst runs-on verwenden, um Runnergruppen als Ziel zu verwenden, sodass der Auftrag auf jedem Runner ausgeführt wird, der Mitglied dieser Gruppe ist. Für eine präzisere Steuerung kannst du auch Runnergruppen mit Bezeichnungen kombinieren.
Runnergruppen können nur größerer Runner oder selbstgehostete Runner als Mitglieder haben.
Beispiel: Verwenden von Gruppen zum Steuern, wo Aufträge ausgeführt werden
In diesem Beispiel wurden Ubuntu-Runner zu einer Gruppe namens ubuntu-runners hinzugefügt. Der runs-on-Schlüssel sendet den Auftrag an einen beliebigen verfügbaren Runner in der Gruppe ubuntu-runners:
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on:
group: ubuntu-runners
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
Beispiel: Kombinieren von Gruppen und Bezeichnungen
Wenn du Gruppen und Bezeichnungen kombinierst, muss der Runner beide Anforderungen erfüllen, um zum Ausführen des Auftrags berechtigt zu sein.
In diesem Beispiel wird eine Runnergruppe namens ubuntu-runners mit Ubuntu-Runnern aufgefüllt, denen zudem die Bezeichnung ubuntu-24.04-16core zugewiesen wurde. Der runs-on-Schlüssel kombiniert group und labels, sodass der Auftrag an einen beliebigen verfügbaren Runner innerhalb der Gruppe weitergeleitet wird, der auch eine übereinstimmende Bezeichnung aufweist:
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on:
group: ubuntu-runners
labels: ubuntu-24.04-16core
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
Beispiel: Verwenden von Präfixen zum Unterscheiden von Runnergruppen
Wenn du beispielsweise eine Runnergruppe mit dem Namen my-group in der Organisation und eine andere Gruppe mit dem Namen my-group im Unternehmen hast, kannst du deine Workflowdatei aktualisieren, sodass org/my-group oder ent/my-group verwendet wird, um zwischen den beiden Gruppen zu unterscheiden.
Verwenden von org/:
runs-on:
group: org/my-group
labels: [ self-hosted, label-1 ]
Verwenden von ent/:
runs-on:
group: ent/my-group
labels: [ self-hosted, label-1 ]