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.
Verwenden von selbstgehosteten Runnern auf Repositoryebene
Möglicherweise kannst du keinen selbstgehosteten Runner für ein Repository im Besitz deiner Organisation erstellen.
Unternehmens- und Organisationsbesitzer*innen können wählen, für welche Repositorys die Erstellung selbstgehosteter Runner auf Repositoryebene erlaubt ist. .
Weitere Informationen findest du unter Erzwingen von Richtlinien für GitHub Actions in deinem Unternehmen und unter GitHub Actions für deine Organisation Deaktivieren oder Einschränken.
Überprüfen des Status eines selbst gehosteten Läufers
Ein selbstgehosteter Runner kann entweder in den Repository-, Organisations- oder Unternehmenseinstellungen auf GitHub Enterprise Server gefunden werden. Um einen selbst-gehosteten Läufer zu verwalten, musst Du über die folgenden Berechtigungen verfügen, abhängig davon, wo der selbst-gehostete Läufer hinzugefügt wurde:
-
Benutzer-Repository: Du musst der Repositorybesitzer sein.
-
Organisation: Du musst ein Organisationsbesitzer sein.
-
Organisationsrepository: Du musst du ein Organisationsbesitzer sein oder über Administratorzugriff auf das Repository verfügen.
-
Unternehmen: Du musst ein GitHub Enterprise-Websiteadministrator sein.
-
Navigiere in deiner Organisation oder deinem Repository zur Hauptseite, und klicke auf Einstellungen.
-
Klicke in der linken Seitenleiste auf Aktionen und dann auf Runner.
-
Unter „Runner“ kannst du eine Liste registrierter Runner, einschließlich Name, Bezeichnungen und Status des Runners, einsehen.
Folgende Statuswerte sind möglich:
- Leerlauf: Der Runner ist mit GitHub Enterprise Server verbunden und bereit, Aufträge auszuführen.
- Aktiv: Der Runner führt derzeit einen Auftrag aus.
- Offline: Der Runner ist nicht mit GitHub Enterprise Server verbunden. Dies könnte daran liegen, dass der Rechner offline ist, die Anwendung für selbst-gehostete Runner nicht auf dem Rechner läuft, oder die Anwendung für selbst-gehostete Runner kann nicht mit GitHub Enterprise Server kommunizieren.
Problembehandlung bei der Netzwerkkonnektivität
Überprüfen der Netzwerkkonnektivität für selbstgehostete Runner
Du kannst das config
-Skript der selbstgehosteten Runneranwendung mit dem Parameter --check
verwenden, um zu überprüfen, ob ein selbstgehosteter Runner auf alle erforderlichen Netzwerkdienste in GitHub zugreifen kann.
Zusätzlich zu --check
müssen zwei weitere Argumente für das Skript angegeben werden:
--url
mit der URL zu deinem bzw. deiner GitHub-Repository, -Organisation oder -Unternehmen. Beispiel:--url https://github.com/octo-org/octo-repo
.--pat
mit dem Wert eines personal access token (classic), der den Geltungsbereichworkflow
haben muss, oder einen fine-grained personal access token mit Lese- und Schreibzugriff für Workflows. Beispiel:--pat ghp_abcd1234
. Weitere Informationen findest du unter Verwalten deiner persönlichen Zugriffstoken.
Beispiel:
./config.sh --check --url URL --pat ghp_abcd1234
./config.sh --check --url URL --pat ghp_abcd1234
config.cmd --check --url https://github.com/YOUR-ORG/YOUR-REPO --pat GHP_ABCD1234
Das Skript testet die einzelnen Dienste und gibt entweder PASS
oder FAIL
für jeden Dienst aus. Wenn die Überprüfung für einen Dienst nicht erfolgreich ist, findest du weitere Einzelheiten in der Protokolldatei der Überprüfung. Die Protokolldateien befinden sich im Verzeichnis _diag
, in dem du die Runneranwendung installiert hast. Der Pfad der Protokolldateien für die einzelnen Überprüfungen wird zudem in der Konsolenausgabe des Skripts angezeigt.
Wenn die Überprüfung für einen Dienst nicht erfolgreich ist, solltest du zudem überprüfen, ob der für deinen selbstgehosteten Runner verwendete Computer alle Kommunikationsanforderungen erfüllt. Weitere Informationen findest du unter Informationen zu selbstgehosteten Runnern.
Deaktivieren der TLS-Zertifikatüberprüfung
Standardmäßig überprüft die selbstgehostete Runneranwendung das TLS-Zertifikat für GitHub Enterprise Server. Wenn GitHub Enterprise Server über ein selbstsigniertes oder intern ausgestelltes Zertifikat verfügt, soll die TLS-Zertifikatüberprüfung zu Testzwecken möglicherweise deaktiviert werden.
Zum Deaktivieren der TLS-Zertifizierungsüberprüfung in der selbstgehosteten Runneranwendung legst du die GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY
-Umgebungsvariable auf 1
fest, bevor du die selbstgehostete Runneranwendung konfigurierst und ausführst.
export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh
export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh
[Environment]::SetEnvironmentVariable('GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY', '1')
./config.cmd --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.cmd
Warning
Die Deaktivierung der TLS-Überprüfung wird nicht empfohlen. Der Grund dafür ist, dass mithilfe von TLS der Datenschutz und die Datenintegrität zwischen der selbstgehosteten Runneranwendung und GitHub Enterprise Server sichergestellt wird. Es wird empfohlen, das GitHub Enterprise Server-Zertifikat im Zertifikatspeicher des Betriebssystems für deinen selbstgehosteten Runner zu installieren. Informationen zur Installation des GitHub Enterprise Server-Zertifikats erhältst du beim Hersteller deines Betriebssystems.
Die Logdateien der Anwendung für selbst-gehostete Runner überprüfen
Du kannst den Status der selbstgehosteten Runneranwendung und die zugehörigen Aktivitäten überwachen. Protokolldateien werden im Verzeichnis _diag
gespeichert, in dem du die Runneranwendung installiert hast. Bei jedem Start der Anwendung wird ein neues Protokoll generiert. Der Dateiname beginnt mit Runner_
, gefolgt von einem UTC-Zeitstempel des Anwendungsstarts.
Warning
Runner-Anwendungsprotokolldateien für kurzlebige Runner müssen für Problembehandlungs- und Diagnosezwecke extern weitergeleitet und beibehalten werden. Weitere Informationen zu selbstgehosteten Runnern finden Sie unter "Automatische Skalierung mit selbstgehosteten Runnern."
Ausführliche Protokolle zur Ausführung von Workflowaufträgen finden Sie im nächsten Abschnitt zu den Dateien vom Typ Worker_
.
Logdatei eines Jobs überprüfen
Die selbstgehostete Runneranwendung erstellt eine detaillierte Protokolldatei für jeden Auftrag, den sie verarbeitet. Diese Dateien werden im Verzeichnis _diag
gespeichert, in dem Sie die Runner-Anwendung installiert haben. Der Dateiname beginnt mit Worker_
.
Den Anwendungs-Dienst für selbst-gehostete Runner mittels journalctl überprüfen
Für Linux-basierte selbstgehostete Runner, die die Anwendung mit einem Dienst ausführen, kannst du zur Überwachung der Echtzeitaktivität journalctl
verwenden. Der standardmäßige systembasierte Dienst verwendet die folgende Namenskonvention: actions.runner.<org>-<repo>.<runnerName>.service
Wenn dieser Name mehr als 80 Zeichen umfasst, wird er abgeschnitten. Aus diesem Grund sollte anhand der Datei .service nach dem Namen des Diensts gesucht werden. Beispiel:
$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service
Wenn dieser Vorgang nicht möglich ist, weil der Dienst an anderer Stelle installiert ist, kannst du den Dienstnamen anhand der Liste der ausgeführten Dienste ermitteln. Auf den meisten Linux-Systemen kannst du z. B. den Befehl systemctl
verwenden:
$ systemctl --type=service | grep actions.runner
actions.runner.octo-org-octo-repo.hostname.service loaded active running GitHub Actions Runner (octo-org-octo-repo.hostname)
Mithilfe von journalctl
kannst du die Echtzeitaktivität des selbstgehosteten Runners überwachen:
sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f
In dieser Beispielausgabe siehst du den Start von runner01
, den Empfang des Auftrags testAction
und den resultierenden Status:
Feb 11 14:57:07 runner01 runsvc.sh[962]: Starting Runner listener with startup type: service
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started listener process
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started running service
Feb 11 14:57:16 runner01 runsvc.sh[962]: √ Connected to GitHub
Feb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Listening for Jobs
Feb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Running job: testAction
Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction completed with result: Succeeded
Zum Anzeigen der systemd
-Konfiguration kannst du hier nach der Dienstdatei suchen: /etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service
.
Diese Datei darf nicht direkt bearbeitet werden, um den Dienst der selbstgehosteten Runneranwendung anzupassen. Befolge die unter Die Anwendung für selbst-gehostete Runner als Dienst konfigurieren beschriebenen Anweisungen.
Überprüfen des selbstgehosteten Runneranwendungsdiensts mit launchd
Für macOS-basierte selbstgehostete Runner, die die Anwendung als Dienst ausführen, kannst du zur Überwachung der Echtzeitaktivität launchctl
verwenden. Der standardmäßige launchd-basierte Dienst verwendet die folgende Namenskonvention: actions.runner.<org>-<repo>.<runnerName>
Wenn dieser Name mehr als 80 Zeichen umfasst, wird er abgeschnitten. Aus diesem Grund sollte anhand der Datei .service im Runnerverzeichnis nach dem Namen des Diensts gesucht werden:
% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist
Das Skript svc.sh
überprüft mithilfe von launchctl
, ob die Anwendung ausgeführt wird. Beispiel:
$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01
Die resultierende Ausgabe enthält die Prozess-ID und den Namen des launchd
-Diensts der Anwendung.
Zum Anzeigen der launchd
-Konfiguration kannst du hier nach der Dienstdatei suchen: /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service
.
Diese Datei darf nicht direkt bearbeitet werden, um den Dienst der selbstgehosteten Runneranwendung anzupassen. Befolge die unter Die Anwendung für selbst-gehostete Runner als Dienst konfigurieren beschriebenen Anweisungen.
Den Anwendungs-Dienst für selbst-gehostete Runner mittels PowerShell überprüfen
Für Windows-basierte selbstgehostete Runner, die die Anwendung als Dienst ausführen, kannst du zur Überwachung der Echtzeitaktivität PowerShell verwenden. Der Dienst verwendet die GitHub Actions Runner (<org>-<repo>.<runnerName>)
-Namenskonvention. Du kannst den Namen des Diensts auch in der .service-Datei im Runnerverzeichnis ermitteln:
PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service
Der Status des Runners kann in der Windows-Anwendung Dienste (services.msc
) angezeigt werden. Darüber hinaus kannst du auch mit PowerShell überprüfen, ob der Dienst ausgeführt wird:
PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
Name Status
---- ------
actions.runner.octo-org-octo-repo.runner01.service Running
Mithilfe von PowerShell kannst du die aktuelle Aktivität des selbstgehosteten Runners überprüfen. In dieser Beispielausgabe siehst du den Anwendungsstart, den Empfang des Auftrags testAction
und den resultierenden Status:
PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerService
Index Time EntryType Source InstanceID Message
----- ---- --------- ------ ---------- -------
136 Mar 17 13:45 Information ActionsRunnerService 100 2020-03-17 13:45:48Z: Job Greeting completed with result: Succeeded
135 Mar 17 13:45 Information ActionsRunnerService 100 2020-03-17 13:45:34Z: Running job: testAction
134 Mar 17 13:41 Information ActionsRunnerService 100 2020-03-17 13:41:54Z: Listening for Jobs
133 Mar 17 13:41 Information ActionsRunnerService 100 û Connected to GitHub
132 Mar 17 13:41 Information ActionsRunnerService 0 Service started successfully.
131 Mar 17 13:41 Information ActionsRunnerService 100 Starting Actions Runner listener
130 Mar 17 13:41 Information ActionsRunnerService 100 Starting Actions Runner Service
129 Mar 17 13:41 Information ActionsRunnerService 100 create event log trace source for actions-runner service
Den automatischen Aktualisierungsprozesses überwachen
Da der selbstgehostete Runner Aufträge nicht verarbeiten kann, wenn eine bestimmte Version unterschritten wird, solltest du den automatischen Updateprozess regelmäßig überprüfen. Die selbstgehostete Runneranwendung aktualisiert sich automatisch selbst. Dieser Vorgang umfasst jedoch keine Updates des Betriebssystems oder anderer Software. Diese Updates müssen separat verwaltet werden.
Die Updateaktivitäten können in den Runner_
-Protokolldateien angezeigt werden. Zum Beispiel:
[Feb 12 12:37:07 INFO SelfUpdater] An update is available.
Weitere Informationen findest du zudem in den SelfUpdate-Protokolldateien im _diag
-Verzeichnis, in dem du die Runneranwendung installiert hast.
Fehlerbehebung für Container in selbst-gehosteten Runnern
Überprüfen, ob Docker installiert ist
Wenn für deine Aufträge Container benötigt werden, muss ein Linux-basierter selbstgehosteter Runner verwendet werden, und Docker muss installiert sein. Überprüfe, ob dein selbstgehosteter Runner über eine Docker-Installation verfügt und der Dienst ausgeführt wird.
Du kannst den Dienststatus mithilfe von systemctl
überprüfen:
$ sudo systemctl is-active docker.service
active
Wenn Docker nicht installiert ist, werden abhängige Aktionen mit den folgenden Fehlern abgebrochen:
[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2020-02-13 16:56:10Z INFO DockerCommandManager] Not found.
[2020-02-13 16:56:10Z ERR StepsRunner] Caught exception from step: System.IO.FileNotFoundException: File not found: 'docker'
Die Docker Berechtigungen überprüfen
Gehe wie folgt vor, wenn dein Auftrag mit dem folgenden Fehler abgebrochen wird:
dial unix /var/run/docker.sock: connect: permission denied
Überprüfe, ob das Dienstkonto des selbstgehosteten Runners für die Verwendung des Docker-Diensts berechtigt ist. Dieses Konto lässt sich anhand der Konfiguration des selbstgehosteten Runners in systemd
ermitteln. Beispiel:
$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user
Auflösen von Runnern, die nach einem Upgrade von GitHub Enterprise Server
offline sind
Wenn Sie kurzlebige Runner nutzen und automatische Updates deaktiviert haben, sollten Sie vor dem Upgraden von GitHub Enterprise Server zunächst die selbstgehosteten Runner auf die Version der Runneranwendung upgraden, die die upgegradete Instanz ausführen wird. Wenn Sie ein Upgrade für GitHub Enterprise Server durchführen, bevor Sie die kurzlebigen Runner upgraden, gehen die Runner unter Umständen offline. Weitere Informationen findest du unter Übersicht über den Upgradeprozess.
Wenn deine Runner aus diesem Grund offline sind, aktualisiere sie manuell. Weitere Informationen findest du in den Installationsanweisungen für die neueste Version im Repository „actions/runner“.
Überprüfen, welche Docker-Engine auf dem Runner installiert ist
Gehe wie folgt vor, wenn dein Build mit dem folgenden Fehler abgebrochen wird:
Error: Input required and not supplied: java-version
Überprüfe, welche Docker-Engine auf deinem selbstgehosteten Runner installiert ist. Um die Eingaben einer Aktion an den Docker-Container zu übergeben, verwendet der Runner Umgebungsvariablen, die Bindestriche in ihren Namen enthalten können. Die Aktion kann die Eingaben möglicherweise nicht abrufen, wenn es sich bei der Docker-Engine nicht um eine binäre ausführbare Datei handelt, sondern um einen Shell-Wrapper oder einen Link, z. B. eine mit snap
unter Linux installierte Docker-Engine. Um diesen Fehler zu beheben, konfiguriere deinen selbstgehosteten Runner so, dass er eine andere Docker-Engine verwendet.
Verwende den Befehl which
, um zu überprüfen, ob deine Docker-Engine mit snap
installiert wurde. Im folgenden Beispiel wurde die Docker-Engine mit snap
installiert:
$ which docker
/snap/bin/docker