Blog

Aktivieren von GitHub-Aktionen auf Enterprise Server: Häufige Stolperfallen

Rob Bos

Rob Bos

Aktualisiert Oktober 15, 2025
7 Minuten

Wenn Kunden damit beginnen, GitHub Enterprise mit Actions und privaten Runnern zu nutzen, gibt es einige häufige Probleme, auf die Sie stoßen können. In diesem Beitrag erzähle ich Ihnen von denen, die mir bisher begegnet sind. Sogar Dependabot ist dabei, denn es läuft auch auf Actions für GitHub Enterprise Server.

Liste der Themen:

  • Zuallererst: Verwenden Sie keine selbstsignierten Zertifikate auf GitHub Enterprise
  • Die Standardaktionen in laden die Binärdateien von github.com herunter
  • Actions org wird bei jeder größeren/kleineren Aktualisierung aufgeräumt
  • Unstimmigkeiten in der Einstellungs-UI (schwieriger für Admins)
  • Es müssen Dependabot-Runner erstellt werden
  • Die Protokollspeicherung erfolgt außerhalb des Servers
  • GitHub Connect ist obligatorisch
  • Denken Sie über GitHub-Aktionen nach und nutzen Sie sie sicher
Bild mit den Logos von Dependabot und GitHub Actions

Die Standardaktionen in der /actions-Organisation laden die Binärdateien von github.com herunter.

Beachten Sie, dass die Standardaktionen in der /actions-Organisation (setup-node, setup-go usw.) die benötigten Binärdateien von github.com. Das bedeutet, dass der Runner diese Dateien ohne Authentifizierung herunterlädt und die Rate nach 60 Downloads/Stunde/ip-Adresse begrenzt wird. Um dies zu umgehen, müssen Sie Ihre eigene Version dieser Aktionen erstellen und die Releases von einer Quelle wie GitHub Releases oder einer internen Quelle wie Artifactory herunterladen oder sie als GitHub Releases in einem Repository speichern.

Actions org wird bei jeder größeren/kleineren Aktualisierung aufgeräumt

Das war keine so angenehme Überraschung: Wir mussten die Standardaktionen anpassen, da setup-node und setup-go die Binärdateien von github.com herunterladen (siehe oben). Unsere Läufer haben aus Sicherheitsgründen keinen Internetzugang. Wir haben unsere eigenen Versionen dieser Aktionen erstellt, die die Binärdateien von unserer internen Artifactory-Instanz herunterladen und sie auf unsere GitHub Enterprise-Instanz hochladen. Das hat eine Zeit lang gut funktioniert, aber als wir von 3.1 auf 3.2 aktualisiert haben, wurde die Actions-Org aufgeräumt und unsere benutzerdefinierten Aktionen waren weg. Für uns war das kein Problem, da wir Kopien des Quellcodes auf mehreren Rechnern hatten, aber es war eine Überraschung. Seien Sie sich also bewusst: Die gesamte Org wird bei jedem größeren/kleineren Update aufgeräumt!

Unstimmigkeiten in den Einstellungen UI: es ist alles durcheinander

Es gibt 2 verschiedene Idiome in den Einstellungen, und wenn Sie über Administratorrechte verfügen (entweder auf Enterprise-, Org- oder Repo-Ebene), werden Sie beide sehen.

  1. UI, in der Sie Änderungen vornehmen und zum Speichern nach unten scrollen müssen
  2. UI, bei der jede Änderung eine Rückmeldung an den Server auslöst und gespeichert wird (und sofort in Kraft tritt)!

Für den zweiten Fall haben wir hier ein Beispiel. Hier gibt es eine Schaltfläche zum Speichern, also.... was denken Sie, wird passieren, wenn Sie die All repositories Einstellung in der Dropdown-Liste?

Screenshot der 'Allgemeinen Aktionsberechtigungen' auf Organisationsebene Diese Einstellung wird sofort an den Server zurückgesendet, so dass die Änderung gespeichert wird und sofort wirksam ist! Die Seite wird zwar kurz neu geladen, aber wenn Sie nicht aufpassen, könnten Sie dies übersehen. Raten Sie mal, wie ich GitHub Actions für alle Benutzer in unserer Produktionsumgebung ausgeschaltet habe? Es dauerte etwas mehr als eine halbe Stunde, bis die Benutzer anfingen, uns anzurufen (mein Team pflegt es), und einen Blick auf diese Seite zu werfen, um zu erfahren, dass die Einstellung geändert wurde.... Das war nicht beabsichtigt, denn ich habe nicht auf die Schaltfläche "Speichern" geklickt!

Es müssen Dependabot-Runner erstellt werden

Wenn Sie Dependabot und seine Versions-Updates aktivieren möchten, müssen Sie dies auf mehreren Ebenen tun: Aktivieren Sie es zunächst auf der Appliance. Ändern Sie dann die Einstellungen für die Organisationsebene, um die Verwendung von Dependabot zu ermöglichen.

Dann können Sie es pro Repo konfigurieren:

  • Aktivieren Sie die Funktion Software Composition Analysis (SCA) (das ist der Startpunkt von Dependabot)
  • Konfigurieren Sie die Datei Dependabot.yml für die Ausführung mit Updates
  • Beachten Sie, dass Dependabot auf Aktionen läuft und die Standard-Setup-Aktion zur Konfiguration des Ökosystems verwendet (mehr dazu unten).
  • Beachten Sie, dass die Dependabot-Läufe ein bestimmtes Label verwenden, mit dem die Läufer angesprochen werden (mehr dazu unten)
  • Erstellen Sie Läufer, die Dependabot verwenden soll (mehr dazu unten)

Dependabot läuft auf Aktionen

Dependabot für Enterprise Server läuft auf Aktionen und ist auf der Registerkarte 'Aktionen' für das Repo sichtbar. Auf diese Weise können Sie deren Ausführung überwachen. Wenn Sie alle Funktionen aktivieren, werden die Aktionen geplant. Erst wenn Sie diese Läufe tatsächlich überprüfen, werden Sie feststellen, dass der Runner ein 'dependabot'-Label als Ziel verwendet. Damit können Sie natürlich kontrollieren, wo diese Läufe stattfinden und wie viele Läufer mit diesen Aufträgen belästigt werden können. Auf diese Weise können die Dependabot-Läufe nicht einfach wahllos alle Ihre mit 'self-hosted' gekennzeichneten Runner in Beschlag nehmen. Sie müssen also Läufer mit dieser Bezeichnung erstellen, bevor etwas passiert.

Tipp: Sehen Sie sich die Dependabot Version updates Workflow-Ausführungsprotokolle an, die auf magische Weise auf der Registerkarte 'Aktionen' erscheinen!

Da es keine API für Dependabot gibt, um die Läufe zu überwachen, oder eine Möglichkeit, die Läufe in der Warteschlange zu sehen und einen Alarm auszulösen, wenn sie länger als 30 Minuten in der Warteschlange stehen (z.B.), gibt es keine gute Möglichkeit, etwas darüber zu erfahren, bis Sie anfangen, danach zu suchen.

Ich fand dies heraus, weil ich nach den Einstellungen suchte und den Workflow-Lauf "stuck in queue" fand. Ein Blick auf die Workflow-Definition sagte mir, was ich wissen musste. Dies ist in den Dokumenten etwas versteckt: Wenn Sie wissen, wo Sie es finden können, und sich durch 4 verschiedene Seiten mit Informationen zur Aktivierung von Dependabot wühlen, finden Sie schließlich diese Referenz dazu, versteckt unter Schritt 3. Ich habe einen Vorschlag gemacht, um zu verdeutlichen, dass Sie dies tun müssen hier (Update: PR akzeptiert!).

Dependabot verwendet eine vorkonfigurierte Workflow-Definition

Diese Definition zieht die setup-node aus Ihrer Aktionsorganisation auf dem Server. Wenn Sie sie mit etwas Eigenem überschreiben (was wir tun mussten, da unsere Runner keine Dinge aus dem Internet herunterladen dürfen), können diese Läufe leicht fehlschlagen (bei uns war das der Fall). Ich habe keine Möglichkeit gefunden, diese Workflow-Datei zu überschreiben, also müssen Sie sicherstellen, dass dies funktioniert. Wir arbeiten derzeit daran, die Dinge für uns einzurichten, was unsere Annahme von Dependabot im Moment stoppt ☹️.

Die Protokollspeicherung erfolgt außerhalb des Servers

GitHub Actions in der SaaS-Version (github.com) wurde mit Blick auf die Ausführung auf Azure erstellt. Alle diese Protokolle werden dann auf einem Cloud-Speicher gespeichert. Derzeit werden Azure Blob Storage und AWS S3 Storage unterstützt. Wenn Sie die Protokolle nicht in einen dieser Speicher verschieben können, gibt es eine Min.io Container einrichten, der die exakte API-Oberfläche eines S3-Buckets hat, das verwendet werden kann, um es über Ihre eigene Speicherlösung zu legen. Sie müssen diesen Speicher erstellen und konfigurieren, bevor Sie fortfahren können.

GitHub Connect ist obligatorisch

Um GitHub Actions verwenden zu können, müssen Sie GitHub Connect aktiviert haben. Dies ist eine Funktion, mit der Sie Ihre GitHub Enterprise Server-Instanz mit GitHub.com verbinden können. Dies ist erforderlich, um den GitHub Marketplace nutzen zu können. Ich bin mir nicht ganz sicher, warum dies der Fall ist, denn die Runner nutzen ihre eigene Internetverbindung, um die Aktionen von github.com herunterzuladen. Der einzige Grund, den ich sehe, ist die Benutzeroberfläche im Workflow-Editor, die es Ihnen ermöglicht, auf dem öffentlichen Marktplatz nach Aktionen zu suchen.

Denken Sie über GitHub-Aktionen nach und nutzen Sie sie sicher

Ich habe darüber geschrieben, wie man GitHub Actions mit einer sicheren Einrichtung verwendet hier und Sie können eine Aufzeichnung meiner Konferenzsitzung auf der Code Europe 2022 hier ansehen.

Sie müssen die Aktionen wirklich prüfen und bewerten, da das Sicherheitsmodell auf Vertrauen basiert. Lesen Sie mehr über den Stand des GitHub Actions Marketplace hier.


Tags:

Verfasst von

Rob Bos

Rob has a strong focus on ALM and DevOps, automating manual tasks and helping teams deliver value to the end-user faster, using DevOps techniques. This is applied on anything Rob comes across, whether it’s an application, infrastructure, serverless or training environments. Additionally, Rob focuses on the management of production environments, including dashboarding, usage statistics for product owners and stakeholders, but also as part of the feedback loop to the developers. A lot of focus goes to GitHub and GitHub Actions, improving the security of applications and DevOps pipelines. Rob is a Trainer (Azure + GitHub), a Microsoft MVP and a LinkedIn Learning Instructor.

Contact

Let’s discuss how we can support your journey.