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. Benutzer mit der Berechtigung „Verwalten von Organisationsrunnern und Runnergruppen“ können nur auswählen, welche Repositorys selbstgehostete Runner auf Repositoryebene für Repositorys in deiner Organisation erstellen dürfen.
Weitere Informationen zu benutzerdefinierten Organisationsrollen findest du unter Informationen zu benutzerdefinierten Organisationsrollen.
Weitere Informationen findest du unter Erzwingen von Richtlinien für Actions in deinem Unternehmen und unter Actions für deine Organisation Deaktivieren oder Einschränken.
Ein selbstgehosteter Runner kann entweder in den Repository-, Organisations- oder Enterprise-Kontoeinstellungen auf 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.
Unternehmenskonto: Du musst ein Unternehmensbesitzer sein.
Navigiere in deiner Organisation oder deinem Repository zur Hauptseite, und klicke auf Settings.
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 verbunden und bereit, Aufträge auszuführen.
- Aktiv: Der Runner führt derzeit einen Auftrag aus.
- Offline: Der Runner ist nicht mit verbunden. Dies könnte daran liegen, dass der Computer offline ist, die Anwendung für selbstgehostete Runner nicht auf dem Computer ausgeführt wird, oder diese Anwendung nicht mit kommunizieren kann.
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 zugreifen kann.
Zusätzlich zu --check müssen zwei weitere Argumente für das Skript angegeben werden:
--urlmit der URL zu deinem bzw. deiner -Repository, -Organisation oder -Unternehmen. Beispiel:--url https://.com/octo-org/octo-repo.--patmit dem Wert eines personal access token (classic), der den Geltungsbereichworkflowhaben 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://.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 Kommunizieren mit selbstgehosteten Runnern.
Standardmäßig überprüft die Anwendung für selbstgehostete Runner das TLS-Zertifikat für . Wenn Netzwerkprobleme auftreten, sollte 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 _ACTIONS_RUNNER_TLS_NO_VERIFY-Umgebungsvariable auf 1 fest, bevor du die selbstgehostete Runneranwendung konfigurierst und ausführst.
export _ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://.com/YOUR-ORG/YOUR-REPO --token
./run.sh
export _ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://.com/YOUR-ORG/YOUR-REPO --token
./run.sh
[Environment]::SetEnvironmentVariable('_ACTIONS_RUNNER_TLS_NO_VERIFY', '1')
./config.cmd --url https://.com/YOUR-ORG/YOUR-REPO --token
./run.cmd
Warnung
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 sichergestellt wird. Es wird empfohlen, das -Zertifikat im Zertifikatspeicher des Betriebssystems für deinen selbstgehosteten Runner zu installieren. Informationen zur Installation des -Zertifikats erhältst du beim Hersteller deines Betriebssystems.
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.
Warnung
Runner-Anwendungsprotokolldateien für kurzlebige Runner müssen für Problembehandlungs- und Diagnosezwecke extern weitergeleitet und beibehalten werden. Weitere Informationen zu selbstgehosteten Runnern findest du 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_.
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_.
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 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
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.
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.
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 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
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
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.
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'
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
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