Überwachen und Behandeln von Problemen mit selbstgehosteten Runnern

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.

1. Navigiere in deiner Organisation oder deinem Repository zur Hauptseite, und klicke auf Settings.

2. Klicke in der linken Seitenleiste auf Aktionen und dann auf Runner.

3. 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 Geltungsbereich workflow haben muss, oder einen fine-grained personal access token mit Lese- und Schreibzugriff für Workflows. Beispiel: --pat ghp_abcd1234. Weitere Informationen finden Sie unter Verwalten deiner persönlichen Zugriffstoken.

Zum 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 finden Sie 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

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.

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_.

$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service

$ 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)

sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f

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

% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist

$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01

PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service

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

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.

$ sudo systemctl is-active docker.service
active

[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'

dial unix /var/run/docker.sock: connect: permission denied

$ 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