Behandeln von Problemen mit GitHub Actions für dein Unternehmen

Überprüfen der Integrität von GitHub Actions

Du kannst die Integrität von GitHub Actions auf Ihre GitHub Enterprise Server-Instance mit dem Befehlszeilen-Hilfsprogramm ghe-actions-check überprüfen. Weitere Informationen findest du unter Befehlszeilenprogramme und unter Auf die Verwaltungsshell (SSH) zugreifen.

Konfigurieren von selbstgehosteten Runnern bei Verwendung eines selbstsignierten Zertifikats für GitHub Enterprise Server

Es wird dringend empfohlen, TLS für GitHub Enterprise Server mit einem Zertifikat zu konfigurieren, das von einem vertrauenswürdigen Aussteller signiert ist. Ein selbst signiertes Zertifikat kann zwar funktionieren, erfordert jedoch zusätzliche Konfiguration für deine selbstgehosteten Runner und wird für Produktionsumgebungen nicht empfohlen. Weitere Informationen findest du unter TLS konfigurieren.

Installieren des Zertifikats auf dem Runnercomputer

Damit ein selbstgehosteter Runner mithilfe eines selbstsignierten Zertifikats eine Verbindung mit einem GitHub Enterprise Server herstellen kann, musst du das Zertifikat auf dem Runnercomputer installieren, damit die Verbindung gehärtet ist.

Die zur Installation eines Zertifikats erforderlichen Schritte findest du in der Dokumentation für das Betriebssystem des Runners.

Konfigurieren von Node.js für die Verwendung des Zertifikats

Die meisten Aktionen werden in JavaScript geschrieben und mithilfe von Node.js ausgeführt, wobei Node.js nicht den Zertifikatspeicher des Betriebssystems verwendet. Damit die selbstgehostete Runneranwendung das Zertifikat verwendet, musst du die Umgebungsvariable NODE_EXTRA_CA_CERTS auf dem Runnercomputer festlegen.

Sie können die Umgebungsvariable als Systemumgebungsvariable festlegen oder sie in einer Datei namens .env im selbstgehosteten Runner-Anwendungsverzeichnis deklarieren (d. h. dem Verzeichnis, in das Sie die Runner-Software heruntergeladen und entpackt haben).

Zum Beispiel:

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

Umgebungsvariablen werden gelesen, wenn die selbstgehostete Runneranwendung gestartet wird. Daher musst du die Umgebungsvariable festlegen, bevor du die Runneranwendung konfigurierst oder startest. Wenn sich deine Zertifikatkonfiguration ändert, musst du die selbstgehostete Runneranwendung neu starten.

Konfigurieren von Docker-Containern für die Verwendung des Zertifikats

Wenn du Docker-Containeraktionen oder Dienstcontainer in deinen Workflows verwendest, musst du das Zertifikat möglicherweise auch in deinem Docker-Image installieren und zusätzlich die oben genannte Umgebungsvariable festlegen.

Konfigurieren von HTTP-Proxyeinstellungen für GitHub Actions

Wenn Sie einen HTTP-Proxyserver auf GitHub konfiguriert haben:

Sie müssen .localhost, 127.0.0.1 und ::1 zu der HTTP-Proxy-Ausschlussliste hinzufügen (in dieser Reihenfolge).
Wenn dein externer Speicherort nicht routingfähig ist, musst du der Ausschlussliste auch die URL zu deinem externen Speicher hinzufügen.

Weitere Informationen zum Ändern deiner Proxyeinstellungen findest du unter Konfigurieren eines ausgehenden Webproxyservers.

Wenn diese Einstellungen nicht ordnungsgemäß konfiguriert sind, erhältst du möglicherweise Fehler, z. B. Resource unexpectedly moved to https://IP-ADDRESS beim Festlegen oder Ändern deiner GitHub Actions-Konfiguration.

Runner, die keine Verbindung zu GitHub Enterprise Server mit einem neuen Hostnamen herstellen

Warnung: Ändere den Hostnamen für GitHub Enterprise Server nach der Ersteinrichtung nicht mehr. Das Ändern des Hostnamens wird zu unerwartetem Verhalten führen, bis hin zu Instanzausfällen und der Ungültigkeit der Sicherheitsschlüssel der Benutzer. Wenn Sie den Hostnamen für Ihre Instanz geändert haben und Probleme auftreten, wenden Sie sich an GitHub Enterprise Support oder GitHub Premium-Support.

Wenn du GitHub Enterprise Server in deiner Umgebung mit einem neuen Hostnamen bereitstellst und der alte Hostname nicht mehr zu deiner Instanz aufgelöst wird, können selbstgehostete Runner keine Verbindung mit dem alten Hostnamen herstellen und keine Aufträge ausführen.

Du musst die Konfiguration deiner selbstgehosteten Runner auf den neuen Hostnamen für Ihre GitHub Enterprise Server-Instance aktualisieren. Jeder selbstgehostete Runner erfordert eine der folgenden Vorgehensweisen:

Bearbeite im Verzeichnis der selbstgehosteten Anwendung die .runner- und .credentials-Dateien, und ersetze alle Erwähnungen des alten Hostnamens durch den neuen. Starte anschließend die selbstgehostete Runneranwendung neu.
Entferne den Runner über die Benutzeroberfläche aus GitHub Enterprise Server, und füge ihn erneut hinzu. Weitere Informationen findest du unter Selbst-gehostete Runner entfernen und unter Selbst-gehostete Runner hinzufügen.

Nicht mehr reagierende Aufträge und Grenzwerte für GitHub Actions -Arbeitsspeicher und -CPU

GitHub Actions bestehen aus einer Vielzahl von Diensten, die auf Ihre GitHub Enterprise Server-Instance ausgeführt werden. Standardmäßig sind diese Dienste mit Standardgrenzwerten für CPU und Arbeitsspeicher konfiguriert, die für die meisten Instanzen funktionieren sollten. Wenn die Nutzung von GitHub Actions in deinem Unternehmen jedoch überdurchschnittlich hoch ausfällt, musst du diese Einstellungen möglicherweise anpassen.

Wenn du feststellst, dass Aufträge nicht gestartet werden (obwohl Runner im Leerlauf vorhanden sind), oder wenn der Fortschritt des Auftrags nicht aktualisiert bzw. nicht in der Benutzeroberfläche geändert wird, kann dies daran liegen, dass die CPU- oder Arbeitsspeichergrenzwerte erreicht sind.

1. Überprüfen der Gesamtauslastung von CPU und Arbeitsspeicher in der Verwaltungskonsole

Öffne auf die Verwaltungskonsole, und überprüfe die Diagramme zur Gesamtauslastung von CPU und Arbeitsspeicher im Überwachungsdashboard unter „Systemintegrität“. Weitere Informationen findest du unter Auf das Überwachungs-Dashboard zugreifen.

Wenn die allgemeine CPU-Gesamtauslastung „Systemintegrität“ bei nahezu 100 Prozent liegt oder kein freier Arbeitsspeicher übrig ist, wird Ihre GitHub Enterprise Server-Instance bei voller Kapazität ausgeführt und muss hochskaliert werden. Weitere Informationen findest du unter CPU- und Arbeitsspeicherressourcen erhöhen.

2. Überprüfen der CPU- und Arbeitsspeicherauslastung von Nomad-Aufträgen in der Verwaltungskonsole

Wenn die Gesamtauslastung von CPU und Arbeitsspeicher unter „Systemintegrität“ im annehmbaren Bereich liegt, scrolle im Überwachungsdashboard nach unten zum Abschnitt „Nomad-Aufträge“, und sieh dir die Diagramme „CPU-Prozentwert“ und „Arbeitsspeichernutzung“ an.

Jeder Plot in diesen Diagrammen entspricht einem Dienst. Suche für GitHub Actions -Dienste nach:

mps_frontend
mps_backend
token_frontend
token_backend
actions_frontend
actions_backend

Wenn einer dieser Dienste bei oder in der Nähe einer 100%igen CPU-Auslastung liegt oder der Speicher seinen Grenzwert fast erreicht hat (standardmäßig 2 GB), muss die Ressourcenzuordnung für diese Dienste möglicherweise erhöht werden. Notieren dir, welche der oben genannten Dienste ihren Grenzwert erreicht oder fast erreicht haben.

3. Erhöhen der Ressourcenzuordnung für Dienste, die ihre Grenzwerte erreicht haben

Melde dich mit SSH bei der Verwaltungsshell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Führe den folgenden Befehl aus, um zu sehen, welche Ressourcen für die Zuordnung verfügbar sind:
```
nomad node status -self
```
Suche in der Ausgabe den Abschnitt „Allocated Resources“ (Zugeordnete Ressourcen). Er sieht etwa folgendermaßen aus:
```
Allocated Resources
CPU              Memory          Disk
7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB
```
Die Ausgabe zeigt, wie viel CPU und Arbeitsspeicher der Gesamtsumme aller Dienste zugeordnet bzw. belegt sind (linker Wert) und wie viel CPU und Arbeitsspeicher verfügbar ist (rechter Wert). Im obigen Beispiel sind 23 GiB von insgesamt 32 GiB Arbeitsspeicher bereits belegt. Dies bedeutet, dass 9 GiB Arbeitsspeicher noch belegt werden können.

Warnung: Achte darauf, nicht mehr als die verfügbaren Ressourcen zuzuordnen. Andernfalls können Dienste nicht mehr gestartet werden.
Wechsle in das Verzeichnis /etc/consul-templates/etc/nomad-jobs/actions:
```
cd /etc/consul-templates/etc/nomad-jobs/actions
```
In diesem Verzeichnis gibt es drei Dateien, die zu den GitHub Actions -Diensten von oben gehören:
- mps.hcl.ctmpl
- token.hcl.ctmpl
- actions.hcl.ctmpl
Öffne für die Dienste, für die du einen Anpassungsbedarf ermittelt hast, die entsprechende Datei, und suche die resources-Gruppe, die wie folgt aussieht:
```
resources {
  cpu = 512
  memory = 2048
  network {
    port "http" { }
  }
}
```
Die Werte sind für CPU-Ressourcen in MHz und für Arbeitsspeicherressourcen MB angegeben.

Um beispielsweise die Ressourcengrenzwerte im obigen Beispiel für die CPU auf 1 GHz und für den Arbeitsspeicher 4 GB zu erhöhen, musst du die Gruppe wie folgt ändern:
```
resources {
  cpu = 1024
  memory = 4096
  network {
    port "http" { }
  }
}
```
Speicher und beende die Datei.
Führe ghe-config-apply aus, um die Änderung zu übernehmen.

Wenn bei der Ausführung von ghe-config-apply eine Ausgabe wie Failed to run nomad job '/etc/nomad-jobs/<name>.hcl' angezeigt wird, wurden CPU- oder Arbeitsspeicherressourcen durch die Änderung wahrscheinlich überbelegt. Wenn dies der Fall ist, bearbeite die Konfigurationsdateien erneut, und senke die CPU- oder Arbeitsspeicherbelegung herab. Führe ghe-config-apply anschließend erneut aus.
Führe nach der Übernahme der Konfiguration ghe-actions-check aus, um zu überprüfen, ob die GitHub Actions -Dienste funktionsfähig sind.

Problembehandlung von Fehlern, wenn Dependabot bestehende Workflows auslöst

Nachdem du Dependabot für Ihre GitHub Enterprise Server-Instance eingerichtet hast, können Fehler angezeigt werden, wenn bestehende Workflows durch Dependabot-Ereignisse ausgelöst werden.

Standardmäßig werden Ausführungen von GitHub Actions-Workflows, die von Dependabot aufgrund von push-, pull_request-, pull_request_review- oder pull_request_review_comment-Ereignissen ausgelöst wurden, so behandelt, als wären sie in einem Repositoryfork geöffnet worden. Im Gegensatz zu Workflows, die von anderen Akteuren ausgelöst werden, erhalten sie ein schreibgeschütztes GitHub-Token (GITHUB_TOKEN) und verfügen nicht über Zugriff auf Geheimnisse, die normalerweise verfügbar sind. Dies führt dazu, dass alle Workflows, die versuchen, in das Repository zu schreiben, fehlschlagen, wenn sie von Dependabot ausgelöst wurden.

Es gibt drei Möglichkeiten, dieses Problem zu beheben:

Du kannst deine Workflows mit einem Ausdruck wie if: github.actor != 'dependabot[bot]' so aktualisieren, dass sie nicht mehr durch Dependabot ausgelöst werden. Weitere Informationen findest du unter Auswerten von Ausdrücken in Workflows und Aktionen.
Du kannst deine Workflows so ändern, dass sie einen zweistufigen Prozess mit pull_request_target verwenden, das nicht diesen Einschränkungen unterliegt. Weitere Informationen findest du unter Automatisieren von Dependabot mit GitHub Actions.
Du kannst Workflows bereitstellen, die durch den Dependabot-Zugriff auf Geheimnisse ausgelöst werden, und es dem Term permissions erlauben, den Standardbereich von GITHUB_TOKEN zu erhöhen. Weitere Informationen sind im Abschnitt „Bereitstellen von Workflows, die durch den Dependabot-Zugriff auf Geheimnisse und erhöhte Berechtigungen ausgelöst werden“ zu finden.

Bereitstellen von Workflows, die durch den Dependabot-Zugriff auf Geheimnisse und erhöhte Berechtigungen ausgelöst werden

Melde dich mit SSH bei der Verwaltungsshell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Um die Einschränkungen für Workflows aufzuheben, die von Dependabot für Ihre GitHub Enterprise Server-Instance ausgelöst werden, führe den folgenden Befehl aus.
```
ghe-config app.actions.disable-dependabot-enforcement true
```
Wende die Konfiguration an.
```
ghe-config-apply
```
Kehre zu GitHub Enterprise Server zurück.

Problembehandlung gebündelter Aktionen in GitHub Actions

Wenn beim Installieren von GitHub Actions in GitHub Enterprise Server der folgende Fehler gemeldet wird, können Sie das Problem beheben, indem Sie die offiziellen gebündelten Aktionen und Workflowvorlagen installieren.

A part of the Actions setup had problems and needs an administrator to resolve.

Gehen Sie wie folgt vor, um die offiziellen gebündelten Aktionen und Workflowvorlagen in einer bestimmten Organisation in GitHub Enterprise Server zu installieren.

Geben Sie eine Organisation an, in der die offiziellen gebündelten Aktionen und Workflowvorlagen gespeichert werden sollen. Du kannst eine neue Organisation erstellen oder eine vorhandene verwenden.
- Informationen zum Erstellen einer neuen Organisation findest du unter Eine neue Organisation von Grund auf erstellen.
- Unterstützung beim Auswählen eines Namens für diese Organisation findest du unter Erste Schritte mit GitHub Actions für GitHub Enterprise Server.
Melde dich mit SSH bei der Verwaltungsshell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Um deine Organisation als Speicherort für gebündelte Aktionen festzulegen, verwende den Befehl ghe-config aus, indem du ORGANIZATION durch den Namen deiner Organisation ersetzt.
```
ghe-config app.actions.actions-org ORGANIZATION
```
und:
```
ghe-config app.actions.github-org ORGANIZATION
```
Um die gebündelten Aktionen zu deiner Organisation hinzuzufügen, lösche den SHA-Wert.
```
ghe-config --unset 'app.actions.actions-repos-sha1sum'
```
Wende die Konfiguration an.
```
ghe-config-apply
```

Nachdem du diese Schritte ausgeführt hast, kannst du die Konfiguration von GitHub Actions unter Erste Schritte mit GitHub Actions für GitHub Enterprise Server fortsetzen.