Skip to main content

Diese Version von GitHub Enterprise Server wird eingestellt am 2026-03-17. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Verwenden von vordefinierten Bausteinen im Workflow

Du kannst vorab geschriebene Aktionen verwenden und anpassen, um deinen Workflow zu unterstützen.

Hinweis

GitHub Actions auf GitHub Enterprise Server verfügt möglicherweise nur über beschränkten Zugriff auf Aktionen auf GitHub.com oder GitHub Marketplace. Weitere Informationen findest du unter Verwalten des Zugriffs auf Aktionen von GitHub.com, oder wende dich an den GitHub Enterprise-Websiteadministrator.

Hinzufügen einer Aktion aus demselben Repository

Wenn eine Aktion im selben Repository definiert wird, in dem deine Workflowdatei diese Aktion verwendet, kannst du entweder mit der {owner}/{repo}@{ref}- oder der ./path/to/dir-Syntax in deiner Workflowdatei auf die Aktion verweisen.

Schritte zum Referenzieren einer Aktion aus demselben Repository:

Die action.yml-Datei wird zum Bereitstellen von Metadaten für die Aktion verwendet. Weitere Informationen zum Inhalt dieser Datei findest du unter Referenz zur Metadatensyntax.

Hinzufügen einer Aktion aus einem anderen Repository

Wenn eine Aktion in einem anderen Repository als deine Workflowdatei definiert ist, kannst du mit der {owner}/{repo}@{ref}-Syntax in deiner Workflowdatei auf diese Aktion verweisen.

Die Aktion muss in einem öffentlichen Repository oder einem internen Repository gespeichert sein, das so konfiguriert ist, dass der Zugriff auf Workflows möglich ist. Weitere Informationen findest du unter Freigeben von Aktionen und Workflows in deinem Unternehmen.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/setup-node@v4

Wenn ein Unternehmensinhaber den Zugriff auf Aktionen auf GitHub.com aktiviert hat, können Sie diese Syntax verwenden, um auf Aktionen entweder innerhalb Ihres Unternehmens oder auf GitHub.com zu verweisen. GitHub Actions sucht zuerst in Ihrem Unternehmen nach der Aktion und greift dann auf GitHub.com zurück.

Verweisen auf einen Container auf Docker Hub

Wenn eine Aktion in einem veröffentlichten Docker-Containerimage auf Docker Hub definiert ist, müssen Sie auf die Aktion mit der Syntax docker://{image}:{tag} in Ihrer Workflowdatei verweisen. Um Ihren Code und Ihre Daten zu schützen, empfehlen wir dringend, die Integrität des Docker-Containerimages vor Docker Hub zu überprüfen, bevor Sie es in Ihrem Workflow verwenden.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8

Unter Workflow zu „Docker-image.yml“ und Creating a Docker container action (Erstellen einer Docker-Containeraktion) findest du einige Beispiele für Docker-Aktionen.

Sicherheitshärtung für die Nutzung von Aktionen in Ihren Workflows

Anwenden der Releaseverwaltung auf deine benutzerdefinierten Aktionen

Die Ersteller*innen einer Communityaktion können Tags, Branches oder SHA-Werte zum Verwalten der Releases der Aktion verwenden. Wie bei allen Abhängigkeiten solltest du die Version der zu verwendenden Aktion abhängig davon angeben, ob du mit automatischen Updates für die Aktion einverstanden bist.

Du legst die Version der Aktion in deiner Workflowdatei fest. Überprüfe die Dokumentation der Aktion, um Informationen zur Releaseverwaltung zu erhalten und zu erfahren, welches Tag, welcher Branch oder welcher SHA-Wert verwendet werden soll.

Hinweis

Es wird empfohlen, beim Verwenden von Aktionen von Drittanbietern einen SHA-Wert zu nutzen. Es ist jedoch wichtig, zu beachten, dass Dependabot nur Dependabot alerts für anfällige GitHub Actions mit semantischer Versionsverwaltung erstellt. Weitere Informationen findest du unter Referenz zur sicheren Verwendung und Informationen zu Dependabot-Warnungen.

Verwenden von Tags

Mit Tags kannst du entscheiden, wann zwischen Haupt- und Nebenversionen gewechselt werden soll. Diese sind jedoch kurzlebiger und können von den Verantwortlichen verschoben oder gelöscht werden. In diesem Beispiel wird gezeigt, wie du eine Aktion anvisieren kannst, die als v1.0.1 getagged wurde.

steps:
  - uses: actions/javascript-action@v1.0.1

Verwenden von SHAs

Wenn du eine zuverlässigere Versionsverwaltung benötigst, solltest du den SHA-Wert verwenden, der der Version der Aktion zugeordnet ist. SHAs sind unveränderlich und daher zuverlässiger als Tags oder Branches. Bei diesem Ansatz erhältst du jedoch keine automatischen Updates für eine Aktion, einschließlich wichtiger Fehlerbehebungen und Sicherheitsupdates. Du musst den vollständigen SHA-Wert eines Commits verwenden, keinen abgekürzten Wert. Wenn du einen SHA auswählen, solltest du überprüfen, ob er aus dem Repository der Aktion und nicht aus einem Repositoryfork stammt. Dieses Beispiel zielt auf den SHA einer Aktion ab:

steps:
  - uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f

Verwenden von Branches

Wenn du einen Zielbranch für die Aktion angibst, wird immer die Version ausgeführt, die sich aktuell auf diesem Branch befindet. Durch diesen Ansatz können Probleme entstehen, wenn ein Update für den Branch Breaking Changes enthält. In diesem Beispiel wird ein Branch namens @main angesprochen:

steps:
  - uses: actions/javascript-action@main

Weitere Informationen finden Sie unter Informationen zu benutzerdefinierten Aktionen.

Verwenden von Eingaben und Ausgaben mit einer Aktion

Eine Aktion akzeptiert oder erfordert häufig Eingaben und generiert Ausgaben, die du verwenden kannst. Beispielsweise musst du bei einer Aktion einen Pfad zu einer Datei, den Namen einer Bezeichnung oder andere Daten angeben, die zur Aktionsverarbeitung verwendet werden.

Überprüfe die action.yml-Datei im Stammverzeichnis des Repositorys, um die Eingaben und Ausgaben einer Aktion anzuzeigen.

Bei action.yml definiert das Schlüsselwort inputs die erforderliche Eingabe namens file-path und enthält einen Standardwert, der verwendet wird, wenn sonst keiner angegeben wird. Das Schlüsselwort outputs definiert eine Ausgabe namens results-file, die angibt, wo die Ergebnisse zu finden sind.

name: "Example"
description: "Receives file and generates output"
inputs:
  file-path: # id of input
    description: "Path to test script"
    required: true
    default: "test-file.js"
outputs:
  results-file: # id of output
    description: "Path to results file"