Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.
- For more information about upgrading to GitHub Enterprise Server 3.0 or later, see "Upgrading GitHub Enterprise Server."
- For more information about configuring GitHub Actions after you upgrade, see the documentation for GitHub Enterprise Server 3.0.
Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.
Den Status eines selbst-gehosteten Runners mittels GitHub überprüfen
A self-hosted runner can be located in either your repository, organization, or enterprise settings on your GitHub Enterprise Server instance. 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:
-
User repository: You must be the repository owner.
-
Organization: You must be an organization owner.
-
Organization repository: You must be an organization owner, or have admin access to the repository.
-
Enterprise: You must be a GitHub Enterprise site administrator.
-
Navigiere in Deiner Organisation oder Deinem Repository zur Hauptseite, und klicke auf Settings (Einstellungen).
-
In the left sidebar, click Actions.
-
Under "Self-hosted runners", you can view a list of registered runners, including the runner's name, labels, and status.
Der Status kann einer der folgenden sein:
- Idle (Leerlauf): Der Runner ist mit GitHub Enterprise Server verbunden und bereit, Jobs auszuführen.
- Active: Der Runner führt derzeit einen Job 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.
Die Logdateien der Anwendung für selbst-gehostete Runner überprüfen
You can monitor the status of the self-hosted runner application and its activities. Log files are kept in the _diag directory, and a new one is generated each time the application is started. The filename begins with Runner_, and is followed by a UTC timestamp of when the application was started.
For detailed logs on workflow job executions, see the next section describing the Worker_ files.
Logdatei eines Jobs überprüfen
The self-hosted runner application creates a detailed log file for each job that it processes. These files are stored in the _diag directory, and the filename begins with Worker_.
Den Anwendungs-Dienst für selbst-gehostete Runner mittels journalctl überprüfen
For Linux-based self-hosted runners running the application using a service, you can use journalctl to monitor their real-time activity. The default systemd-based service uses the following naming convention: actions.runner.<org>-<repo>.<runnerName>.service. This name is truncated if it exceeds 80 characters, so the preferred way of finding the service's name is by checking the .service file. Ein Beispiel:
$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.serviceYou can use journalctl to monitor the real-time activity of the self-hosted runner:
$ sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -fIn this example output, you can see runner01 start, receive a job named testAction, and then display the resulting 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: SucceededTo view the systemd configuration, you can locate the service file here: /etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service. If you want to customize the self-hosted runner application service, do not directly modify this file. Follow the instructions described in "Configuring the self-hosted runner application as a service."
Den Anwendungs-Dienst für selbst-gehostete Runner mittels „launchd“ überprüfen
For macOS-based self-hosted runners running the application as a service, you can use launchctl to monitor their real-time activity. The default launchd-based service uses the following naming convention: actions.runner.<org>-<repo>.<runnerName>. This name is truncated if it exceeds 80 characters, so the preferred way of finding the service's name is by checking the .service file in the runner directory:
% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plistThe svc.sh script uses launchctl to check whether the application is running. Ein Beispiel:
$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01The resulting output includes the process ID and the name of the application’s launchd service.
To view the launchd configuration, you can locate the service file here: /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service. If you want to customize the self-hosted runner application service, do not directly modify this file. Follow the instructions described in "Configuring the self-hosted runner application as a service."
Den Anwendungs-Dienst für selbst-gehostete Runner mittels PowerShell überprüfen
For Windows-based self-hosted runners running the application as a service, you can use PowerShell to monitor their real-time activity. The service uses the naming convention GitHub Actions Runner (<org>-<repo>.<runnerName>). You can also find the service's name by checking the .service file in the runner directory:
PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.serviceYou can view the status of the runner in the Windows Services application (services.msc). You can also use PowerShell to check whether the service is running:
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 RunningYou can use PowerShell to check the recent activity of the self-hosted runner. In this example output, you can see the application start, receive a job named testAction, and then display the resulting 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 serviceDen automatischen Aktualisierungsprozesses überwachen
We recommend that you regularly check the automatic update process, as the self-hosted runner will not be able to process jobs if it falls below a certain version threshold. The self-hosted runner application automatically updates itself, but note that this process does not include any updates to the operating system or other software; you will need to separately manage these updates.
You can view the update activities in the Runner_ log files. Ein Beispiel:
[Feb 12 12:37:07 INFO SelfUpdater] An update is available.In addition, you can find more information in the SelfUpdate log files located in the _diag directory.
Fehlerbehebung für Container in selbst-gehosteten Runnern
Überprüfen, ob Docker installiert ist
If your jobs require containers, then the self-hosted runner must be Linux-based and needs to have Docker installed. Check that your self-hosted runner has Docker installed and that the service is running.
You can use systemctl to check the service status:
$ sudo systemctl is-active docker.service
activeIf Docker is not installed, then dependent actions will fail with the following errors:
[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
If your job fails with the following error:
dial unix /var/run/docker.sock: connect: permission deniedCheck that the self-hosted runner's service account has permission to use the Docker service. You can identify this account by checking the configuration of the self-hosted runner in systemd. Ein Beispiel:
$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user