Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.
Übersicht
Mit Starterworkflows können alle Personen in Ihrer Organisation, die über die entsprechenden Berechtigungen verfügen, Workflows schneller und leichter erstellen. Bei der Erstellung eines neuen Workflows kannst du einen Startworkflow auswählen. So wird dir das Schreiben des Workflows ganz oder teilweise abgenommen. Du kannst Startworkflows als Ausgangspunkt verwenden, um deinen eigenen benutzerdefinierten Workflow zu erstellen, oder du kannst sie unverändert übernehmen. So sparst du nicht nur Zeit, sondern sorgst auch für Konsistenz und den Einsatz bewährter Methoden in deiner Organisation.
GitHub bietet einsatzbereite Start-Workflows für die folgenden Kategorien auf hoher Ebene:
-
Bereitstellung (CD) . Weitere Informationen findest du unter Informationen zu Continuous Deployment.
-
Continuous Integration (CI) Weitere Informationen findest du unter Informationen zur fortlaufenden Integration.
-
Automatisierung. Automatisierungsstart-Workflows bieten Lösungen für die Automatisierung von Workflows, so wie das Triagieren von Pull Requests und das Anwenden einer Bezeichnung basierend auf den Pfaden, die in der Pull Request geändert werden, oder Begrüßungen für Benutzer, die zum ersten Mal mitwirkende Personen des Repositorys sind.
Erstellen eines Startworkflows
Startworkflows können von Benutzer*innen mit Schreibzugriff auf das .github
-Repository der Organisation erstellt werden. Diese können dann von Organisationsmitgliedern verwendet werden, die über die Berechtigung zum Erstellen von Workflows verfügen.
Hinweis: Du kannst wiederverwendbare Workflows innerhalb eines Workflows abrufen, um die Duplizierung zwischen Startworkflows zu vermeiden. Dies kann die Verwaltung von Workflows vereinfachen. Weitere Informationen findest du unter Wiederverwenden von Workflows.
In diesem Verfahren wird veranschaulicht, wie du einen Startworkflow und eine Metadatendatei erstellen kannst. Die Metadatendatei beschreibt, wie der Startworklow Benutzer*innen beim Erstellen eines neuen Workflows zur Verfügung gestellt wird.
-
Wenn diese noch nicht vorhanden ist, solltest du ein neues öffentliches Repository mit dem Namen
.github
in deiner Organisation erstellen. -
Erstelle ein Verzeichnis namens
workflow-templates
. -
Erstelle die neue Workflowdatei im Verzeichnis
workflow-templates
.Wenn du auf den Standardbranch eines Repositorys verweisen musst, kannst du den Platzhalter
$default-branch
verwenden. Beim Erstellen eines Workflows wird der Platzhalter automatisch durch den Namen des Standardbranches des Repositorys ersetzt.
Hinweis: Die folgenden Werte im runs-on
-Schlüssel werden auch als Platzhalter behandelt:
- „ubuntu-latest“ wird durch „[ self-hosted ]“ ersetzt.
- „windows-latest“ wird durch „[ self-hosted, windows ]“ ersetzt.
- „macos-latest“ wird durch „[ self-hosted, macOS ]“ ersetzt.
Die Datei octo-organization-ci.yml
veranschaulicht beispielsweise einen grundlegenden Workflow.
name: Octo Organization CI on: push: branches: [ $default-branch ] pull_request: branches: [ $default-branch ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run a one-line script run: echo Hello from Octo Organization
name: Octo Organization CI
on:
push:
branches: [ $default-branch ]
pull_request:
branches: [ $default-branch ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run a one-line script
run: echo Hello from Octo Organization
-
Erstelle im Verzeichnis
workflow-templates
eine Metadatendatei. Die Metadatendatei muss denselben Namen wie die Workflowdatei tragen, aber statt der.yml
-Erweiterung muss.properties.json
angefügt sein. Beispielsweise enthält die Dateiocto-organization-ci.properties.json
die Metadatei für den Workflowocto-organization-ci.yml
:JSON { "name": "Octo Organization Workflow", "description": "Octo Organization CI starter workflow.", "iconName": "example-icon", "categories": [ "Go" ], "filePatterns": [ "package.json$", "^Dockerfile", ".*\\.md$" ] }
{ "name": "Octo Organization Workflow", "description": "Octo Organization CI starter workflow.", "iconName": "example-icon", "categories": [ "Go" ], "filePatterns": [ "package.json$", "^Dockerfile", ".*\\.md$" ] }
-
name
- Muss angegeben werden. Der Name des Workflows. Dieser wird in der Liste der verfügbaren Workflows angezeigt. -
description
- Muss angegeben werden. Die Beschreibung des Workflows. Diese wird in der Liste der verfügbaren Workflows angezeigt. -
iconName
- Kann optional angegeben werden. Legt ein Symbol für den Workflow fest, das in der Liste der Workflows angezeigt wird.iconName
kann einem der folgenden Typen entsprechen:- Eine SVG-Datei, die im Verzeichnis
workflow-templates
gespeichert ist. Um auf eine Datei zu verweisen, muss der Wert dem Dateinamen ohne Dateierweiterung entsprechen. Beispielsweise wird auf eine SVG-Datei mit dem Namenexample-icon.svg
alsexample-icon
verwiesen. - Ein Symbol aus der Octicon-Gruppe von GitHub. Um auf ein Octicon zu verweisen, muss der Wert
octicon <icon name>
lauten. Beispielsweiseocticon smiley
.
- Eine SVG-Datei, die im Verzeichnis
-
categories
- Kann optional angegeben werden. Definiert die Kategorien, unter denen der Workflow angezeigt wird. Du kannst Kategorienamen aus den folgenden Listen verwenden:- Allgemeine Kategorienamen aus dem Repository starter-workflows.
- Linguist-Sprachen aus der Liste im Repository linguist.
- Unterstützte Technologiestapel aus der Liste im Repository starter-workflows.
-
filePatterns
- Kann optional angegeben werden. Dies ermöglicht die Verwendung des Workflows, wenn sich im Repository des Benutzers bzw. der Benutzerin eine Datei im Stammverzeichnis befindet, die einem definierten regulären Ausdruck entspricht.
-
Füge die Dateien zum gleichen workflow-templates
-Verzeichnis hinzu, um einen anderen Startworkflow hinzuzufügen.
Nächste Schritte
Weitere Informationen zu GitHub Actions findest du unter Verwenden von Startworkflows.