Skip to main content
Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.

Diese Version von GitHub Enterprise wurde eingestellt am 2023-03-15. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Verwenden selbstgehosteten Runnern in einem Workflow

Um selbstgehostete Runner in einem Workflow zu verwenden, kannst du Bezeichnungen verwenden, um den Runner für einen Auftrag anzugeben.

Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

Du kannst selbstgehostete Runner für die Verwendung in einem Workflow basierend auf den Bezeichnungen, die den Runnern zugewiesen sind, als Ziel verwenden.

Informationen zu Bezeichnungen für selbstgehostete Runner

Mithilfe von Bezeichnungen kannst du Workflowaufträge entsprechend ihrer gemeinsamen Merkmale an bestimmte Typen von selbstgehosteten Runnern senden. Wenn dein Auftrag beispielsweise eine bestimmte Hardwarekomponente oder ein bestimmtes Softwarepaket benötigt, kannst du einem Runner eine benutzerdefiniertes Bezeichnung zuweisen und dann deinen Auftrag so konfigurieren, dass er nur auf Runnern mit dieser Bezeichnung ausgeführt wird.

Um einen selbstgehosteten Runner für deinen Auftrag anzugeben, konfiguriere runs-on in deiner Workflowdatei mit Bezeichnungen selbstgehosteter Runner.

Alle selbstgehosteten Runner weisen die Bezeichnung self-hosted auf. Wenn du nur diese Bezeichnung verwendest, werden dadurch alle selbstgehosteten Runner ausgewählt. Um Runner auszuwählen, die bestimmte Kriterien erfüllen, z. B. im Hinblick auf Betriebssystem oder Architektur, empfehlen wir 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.

Die Bezeichnung self-hosted ist zwar nicht erforderlich, wird aber bei Verwendung selbstgehosteter Runner dringend empfohlen. So wird sichergestellt, dass in deinem Auftrag nicht versehentlich aktuelle oder zukünftige von GitHub gehostete Runner angegeben werden.

Informationen zum Erstellen von benutzerdefinierten und Standardbezeichnungen findest du unter Verwenden von Bezeichnungen mit selbstgehosteten Runnern.

Standard-Labels verwenden, um Jobs zu lenken

Ein selbst-gehosteter Runner erhält automatisch bestimmte Labels, wenn er zu GitHub Actions hinzugefügt wird. Diese werden verwendet, um das Betriebssystem und die Hardwareplattform anzuzeigen:

  • self-hosted: Standardbezeichnung, die auf alle selbstgehosteten Runner angewendet wird.
  • linux, windows oder macOS: Wird je nach Betriebssystem des Runners angewendet.
  • x64, ARModer ARM64: Wird je nach Hardwarearchitektur angewendet.

Du kannst die YAML deines Workflows verwenden, um Aufträge an eine Kombination dieser Bezeichnungen zu senden. In diesem Beispiel ist ein selbst-gehosteter Runner, der allen drei Labels entspricht, berechtigt, den Job auszuführen:

runs-on: [self-hosted, linux, ARM64]
  • self-hosted – Auftrag auf einem selbstgehosteten Runner ausführen.
  • linux – Nur Linux-basierten Runner verwenden.
  • ARM64 – Nur auf ARM64-Hardware basierenden Runner verwenden.

Die Standard-Labels sind fest und können weder geändert noch entfernt werden. Erwäge die Verwendung benutzerdefinierter Bezeichnungen, wenn du mehr Kontrolle über das Auftragsrouting benötigst.

Benutzerdefinierte Labels verwenden, um Jobs zu lenken

Du kannst jederzeit eigene Bezeichnungen erstellen und deinen selbstgehosteten Runnern zuordnen. Mit benutzerdefinierten Bezeichnungen kannst du Aufträge an bestimmte Typen von selbstgehosteten Runnern senden, je nachdem, welche Bezeichnungen sie haben.

Wenn du z. B. einen Auftrag hast, der einen bestimmten Typ von Grafikhardware erfordert, kannst du eine benutzerdefinierte Bezeichnung mit dem Namen gpu erstellen und den Runnern zuordnen, auf denen diese Hardware installiert ist. Ein selbst-gehosteter Runner, der allen zugewiesenen Labels entspricht, ist dann berechtigt, den Job auszuführen.

Dieses Beispiel zeigt einen Job, der Standard- und benutzerdefinierte Labels kombiniert:

runs-on: [self-hosted, linux, x64, gpu]
  • self-hosted – Auftrag auf einem selbstgehosteten Runner ausführen.
  • linux – Nur Linux-basierten Runner verwenden.
  • x64 – Nur auf x64-Hardware basierenden Runner verwenden.
  • gpu – Diese benutzerdefinierte Bezeichnung wurde manuell selbstgehosteten Runnern zugewiesen, auf denen die GPU-Hardware installiert ist.

Diese Bezeichnungen funktionieren kumulativ. Ein selbstgehosteter Runner muss also alle vier Bezeichnungen aufweisen, um den Auftrag verarbeiten zu können.

Routingrangfolge für selbstgehostete Runner

Wenn du einen Auftrag an einen selbstgehosteten Runner weiterleitest, sucht GitHub nach einem Runner, der mit den runs-on-Bezeichnungen des Auftrags übereinstimmt:

  • Wenn GitHub einen online und im Leerlauf befindlichen Runner findet, der mit den runs-on-Bezeichnungen des Auftrags übereinstimmt, wird der Auftrag dem Runner zugewiesen und zugesendet.
    • Wenn der Runner den zugewiesenen Auftrag nicht innerhalb von 60 Sekunden abholt, wird der Auftrag erneut in die Warteschlange gestellt, sodass er von einem neuen Runner angenommen werden kann.
  • Wenn GitHub keinen online und im Leerlauf befindlichen Runner findet, der mit den runs-on-Bezeichnungen des Auftrags übereinstimmt, bleibt der Auftrag in der Warteschlange, bis ein Runner online geht.
  • Wenn der Auftrag länger als 24 Stunden in der Warteschlange bleibt, schlägt der Auftrag fehl.