# Wiederverwenden von Workflowkonfigurationen Hier finden Sie Informationen zum Vermeiden von Duplizierungen beim Erstellen eines Workflows, indem Sie vorhandene Workflows verwenden. ## Wiederverwendbare Workflows Referenzinformationen für wiederverwendbare Workflows ### Zugriff auf wiederverwendbare Workflows Ein wiederverwendbarer Workflow kann von einem anderen Workflow verwendet werden, wenn einer der folgenden Punkte zutrifft: * Beide Workflows befinden sich im selben Repository. * Der aufgerufene Workflow wird in einem öffentlichen Repositoryund In Ihrer können Sie öffentliche wiederverwendbare Workflows verwenden. * Der aufgerufene Workflow befindet sich in einem privaten Repository, und die Einstellungen für dieses Repository ermöglichen den Zugriff darauf. Weitere Informationen finden Sie unter [Teilen von Aktionen und Workflows in Ihrer Organisation](/de/actions/how-tos/reuse-automations/share-with-your-organization) und [Freigeben von Aktionen und Workflows in deinem privaten Repository](/de/actions/how-tos/reuse-automations/share-across-private-repositories). Die folgende Tabelle zeigt die Zugänglichkeit wiederverwendbarer Workflows für einen Aufrufer-Workflow, abhängig von der Sichtbarkeit des Host-Repositorys. | Anrufer-Repository | Repositorys für zugängliche Workflows | | ------------------ | ------------------------------------- | | `private` | | | `private` | | | `public` | | | | | | `public` | `public` | Die **Actions Berechtigungen** auf der Seite „Actions-Einstellungen“ des Aufrufer-Repositorys müssen so konfiguriert werden, dass die Nutzung von Aktionen und wiederverwendbaren Workflows ermöglicht wird. Weitere Informationen findest du unter [Einstellung der GitHub Actions für ein Repository verwalten](/de/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-select-actions-and-reusable-workflows-to-run). Für private Repositorys muss die **Access-Richtlinie** auf der Seite "Aktionen"-Einstellungen des repositorys des aufgerufenen Workflows explizit konfiguriert werden, um den Zugriff von Repositorys zuzulassen, die Aufruferworkflows enthalten - siehe [Einstellung der GitHub Actions für ein Repository verwalten](/de/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository). > \[!NOTE] > Um die Sicherheit zu erhöhen, unterstützt GitHub Actions keine Umleitungen für Aktionen oder wiederverwendbare Workflows. Dies bedeutet, dass bei einer Änderung des Besitzers bzw. der Besitzerin, des Namens des Repositorys einer Aktion oder des Namens einer Aktion alle Workflows, die diese Aktion mit dem vorherigen Namen verwenden, fehlschlagen. ### Einschränkungen von wiederverwendbaren Workflows * Sie können bis zu zehn Ebenen von Workflows verbinden. Weitere Informationen findest du unter [Verschachteln wiederverwendbarer Workflows](/de/actions/how-tos/reuse-automations/reuse-workflows#nesting-reusable-workflows). * Sie können maximal 50 eindeutige wiederverwendbare Workflows aus einer einzigen Workflowdatei aufrufen. Dieser Grenzwert gilt für alle Strukturen von geschachtelten wiederverwendbaren Workflows, die ab der Workflowdatei der aufrufenden Funktion der obersten Ebene aufgerufen werden können. Beispielsweise zählt *top-level-caller-workflow\.yml* → *called-workflow-1.yml* → *called-workflow-2.yml* als zwei wiederverwendbare Workflows. * Alle Umgebungsvariablen, die in einem `env`-Kontext festgelegt werden, der im aufrufenden Workflow auf Workflowebene definiert ist, werden nicht an den aufgerufenen Workflow übergeben. Weitere Informationen findest du unter [Speichern von Informationen in Variablen](/de/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables) und [Kontextreferenz](/de/actions/reference/workflows-and-actions/contexts#env-context). * Auf ähnliche Weise sind im `env`-Kontext festgelegte Umgebungsvariablen, die im aufgerufenen Workflow definiert sind, im `env`-Kontext des Aufruferworkflows nicht zugänglich. Stattdessen musst du Ausgaben des wiederverwendbaren Workflows verwenden. Weitere Informationen findest du unter [Verwenden von Ausgaben eines wiederverwendbaren Workflows](/de/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow). * Um Variablen in mehreren Workflows wiederzuverwenden, lege sie auf Organisations-, Repository- oder Umgebungsebene fest, und verweise mithilfe des Kontexts `vars` darauf. Weitere Informationen findest du unter [Speichern von Informationen in Variablen](/de/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables) und [Kontextreferenz](/de/actions/reference/workflows-and-actions/contexts#vars-context). * Wiederverwendbare Workflows werden direkt in einem Auftrag aufgerufen und nicht innerhalb eines Arbeitsschritts. Du kannst daher `GITHUB_ENV` verwenden, um Werte an die Auftragsschritte im Aufruferworkflow zu übergeben. ### Unterstützte Schlüsselwörter für Aufträge, in denen ein wiederverwendbarer Workflow aufgerufen wird Beim Aufrufen eines wiederverwendbaren Workflows kannst du in dem Auftrag, der den Aufruf enthält, nur die folgenden Schlüsselwörter verwenden: * [`jobs..name`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idname) * [`jobs..uses`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iduses) * [`jobs..with`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwith) * [`jobs..with.`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwithinput_id) * [`jobs..secrets`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecrets) * [`jobs..secrets.`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretssecret_id) * [`jobs..secrets.inherit`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretsinherit) * [`jobs..strategy`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategy) * [`jobs..needs`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds) * [`jobs..if`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idif) * [`jobs..concurrency`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idconcurrency) * [`jobs..permissions`](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idpermissions) > \[!NOTE] > > * Wenn im aufrufenden Auftrag `jobs..permissions` nicht angegeben ist, verfügt der aufgerufene Workflow über die Standardberechtigungen für `GITHUB_TOKEN`. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#permissions). > * Die vom aufrufenden Workflow übergebene `GITHUB_TOKEN`-Berechtigungen können vom aufgerufenen Workflow nur herabgestuft (nicht erweitert) werden. > * Wenn Sie `jobs..concurrency.cancel-in-progress: true` verwenden, dürfen Sie für `jobs..concurrency.group` in den aufgerufenen und aufrufenden Workflows nicht gen gleichen Wert verwenden, da sonst der bereits ausgeführte Workflow abgebrochen wird. Ein aufgerufener Workflow verwendet den Namen des aufrufenden Workflows in ${{ github.workflow }}, also wird, wenn Sie diesen Kontext als Wert in `jobs..concurrency.group` sowohl im aufrufenden als auch im aufgerufenen Workflow verwenden, der Aufrufer-Workflow abgebrochen, wenn der aufgerufene Workflow ausgeführt wird. ### Wie wiederverwendbare Workflows Runner nutzen #### GitHub-gehostete Runner Die Zuweisung von GitHubgehosteten Runnern wird immer nur mit dem Kontext des Aufrufers ausgewertet. Die Abrechnung für GitHub-gehostete Runner ist immer mit dem Aufrufer verknüpft. Der Aufrufer-Workflow kann keine GitHub-gehosteten Runner vom aufgerufenen Repository verwenden. Weitere Informationen finden Sie unter [Von GitHub gehostete Runner](/de/actions/concepts/runners/github-hosted-runners). #### Selbstgehosteten Runnern Aufgerufene Workflows, die demselben Benutzer, derselben Organisation gehören wie der aufrufende Workflow, können über den Kontext des Aufrufers auf selbst gehostete Runner zugreifen. Dies bedeutet, dass ein aufgerufener Workflow auf selbstgehostete Runner zugreifen kann, auf die Folgendes zutrifft: * Du befindest dich im Repository des aufrufenden Workflows. * In der Organisation des aufrufenden Repositorys, sofern der Runner dem aufrufenden Repository zur Verfügung gestellt wurde ### Zugriff und Berechtigungen für geschachtelte Workflows Ein Workflow, der geschachtelte wiederverwendbare Workflows enthält, schlägt fehl, wenn einer der geschachtelten Workflows für den anfänglichen aufrufenden Workflow nicht zugänglich ist. Weitere Informationen findest du unter [Zugriff auf wiederverwendbare Workflows](#access-to-reusable-workflows). `GITHUB_TOKEN`-Berechtigungen müssen in geschachtelten Workflows identisch oder restriktiver sein. In der Workflowkette A > B > C gilt beispielsweise Folgendes: Wenn Workflow A über die Tokenberechtigung `package: read` verfügt, können B und C nicht die Berechtigung `package: write` aufweisen. Weitere Informationen finden Sie unter [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/actions/tutorials/authenticate-with-github_token). Informationen dazu, wie du mithilfe der API ermitteln kannst, welche Workflowdateien an einer bestimmten Workflowausführung beteiligt waren, findest du unter [Wiederverwenden von Workflows](/de/actions/how-tos/reuse-automations/reuse-workflows#monitoring-which-workflows-are-being-used). ### Verhalten von wiederverwendbaren Workflows beim erneuten Ausführen von Aufträgen Auf wiederverwendbare Workflows aus öffentlichen Repositorys kann mithilfe eines SHA, eines Releasetags oder eines Branchnamens verwiesen werden. Weitere Informationen finden Sie unter [Wiederverwenden von Workflows](/de/actions/how-tos/reuse-automations/reuse-workflows#calling-a-reusable-workflow). Wenn du einen Workflow, der einen wiederverwendbaren Workflow verwendet, erneut ausführst, und der Verweis kein SHA-Verweis ist, sind einige Verhaltensweisen zu beachten: * Bei erneuter Ausführung aller Aufträge in einem Workflow wird der wiederverwendbare Workflow aus dem angegebenen Verweis verwendet. Weitere Informationen zum erneuten Ausführen aller Aufträge in einem Workflow findest du unter [Erneutes Ausführen von Workflows und Jobs](/de/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-all-the-jobs-in-a-workflow). * Beim erneuten Ausführen von fehlerhaften Aufträgen oder eines bestimmten Auftrags in einem Workflow wird derselbe wiederverwendbare Workflow mit demselben Commit-SHA wie beim ersten Versuch verwendet. Weitere Informationen zum erneuten Ausführen fehlerhafter Aufträge in einem Workflow findest du unter [Erneutes Ausführen von Workflows und Jobs](/de/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow). Weitere Informationen zum erneuten Ausführen eines bestimmten Auftrags in einem Workflow findest du unter [Erneutes Ausführen von Workflows und Jobs](/de/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-a-specific-job-in-a-workflow). ### Kontext `github` Wenn ein wiederverwendbarer Workflow durch einen aufrufenden Workflow ausgelöst wird, wird der Kontext `github` immer dem aufrufenden Workflow zugeordnet. Dem aufgerufenen Workflow wird automatisch Zugriff auf `github.token` und `secrets.GITHUB_TOKEN` gewährt. Weitere Informationen zum `github`-Kontext findest du unter [Kontextreferenz](/de/actions/reference/workflows-and-actions/contexts#github-context). ## Workflowvorlagen Referenzinformationen, die beim Erstellen von Workflowvorlagen für deine Organisation verwendet werden sollen ### Verfügbarkeit von Workflowvorlagen Du kannst Vorlagen in Repositorys verwenden, die mit dem Vorlagenrepository übereinstimmen oder eine eingeschränktere Sichtbarkeit als das Vorlagenrepository aufweisen. * Workflowvorlagen in einem öffentlichen `.github`-Repository sind für alle Repositorytypen verfügbar. * Workflowvorlagen in einem internen `.github`-Repository sind lediglich für interne und private Repositorys verfügbar. * Workflowvorlagen in einem privaten `.github`-Repository sind ausschließlich für private Repositorys verfügbar. ### Gewähren des Zugriffs für private oder interne Repositorys Wenn du ein privates oder internes `.github`-Repository verwendest, musst du Benutzern oder Teams Lesezugriff gewähren, die die Vorlagen verwenden können sollten. ### Platzhalter `$default-branch` Wenn du auf den Standardbranch eines Repositorys verweisen musst, kannst du in deiner Workflowvorlage den Platzhalter `$default-branch` verwenden. Wenn ein Workflow erstellt wird, wird der Platzhalter automatisch durch den Namen des Standardzweigs des Repositorys ersetzt. ### Beispieldatei für eine Workflowvorlage Die Datei `octo-organization-ci.yml` veranschaulicht einen einfachen Workflow. ```yaml copy name: Octo Organization CI on: push: branches: [ $default-branch ] pull_request: branches: [ $default-branch ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - name: Run a one-line script run: echo Hello from Octo Organization ``` ### Anforderungen an Metadatendateien Die Metadatendatei muss denselben Namen wie die Workflowdatei tragen, aber statt der `.yml`-Erweiterung muss `.properties.json` angefügt sein. Beispielsweise enthält die Datei `octo-organization-ci.properties.json` die Metadatei für den Workflow `octo-organization-ci.yml`: ```json copy { "name": "Octo Organization Workflow", "description": "Octo Organization CI workflow template.", "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. Dieser wird in der Liste der verfügbaren Workflows angezeigt. * `iconName` - **Optional:** Legt ein Symbol für den Workflow fest, das in der Liste der Workflows angezeigt wird. `iconName` kann eine der folgenden Typen sein: * 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 Namen `example-icon.svg` als `example-icon` verwiesen. * Ein Symbol aus der [Octicon](https://primer.style/octicons/)-Gruppe von GitHub. Um auf ein Octicon zu verweisen, muss der Wert `octicon ` lauten. Beispiel: `octicon smiley`. * `categories` - **Optional:** Definiert die Kategorien, unter denen der Workflow angezeigt wird. Du kannst Kategorienamen aus den folgenden Listen verwenden: * Allgemeine Kategorienamen aus dem Repository [starter-workflows](https://github.com/actions/starter-workflows/blob/main/README.md#categories). * Linguist-Sprachen aus der Liste im Repository [linguist](https://github.com/github-linguist/linguist/blob/main/lib/linguist/languages.yml). * Unterstützte Technologiestapel aus der Liste im Repository [starter-workflows](https://github.com/github-starter-workflows/repo-analysis-partner/blob/main/tech_stacks.yml). * `filePatterns` - **Optional:** 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. ## YAML-Anker und -Aliase Du kannst YAML-Anker und Aliase verwenden, um Wiederholungen in deinen Workflows zu reduzieren. Ein Anker (durch `&` gekennzeichnet) identifiziert einen Inhalt, den du wiederverwenden möchtest, wohingegen ein Alias (durch `*`gekennzeichnet) diesen Inhalt an einer anderen Stelle wiederholt. Ausführliche Informationen zu Ankern und Aliasen findest du unter [Knotenanker und -aliase in der YAML-Spezifikation](https://yaml.org/spec/1.2.2/#3222-anchors-and-aliases). Im folgenden Beispiel werden YAML-Anker und -Aliase mit Umgebungsvariablen verwendet: ```yaml jobs: job1: env: &env_vars # Define the anchor on first use NODE_ENV: production DATABASE_URL: ${{ secrets.DATABASE_URL }} steps: - run: echo "Using production settings" job2: env: *env_vars # Reuse the environment variables steps: - run: echo "Same environment variables here" ``` Das entspricht dem Schreiben des folgenden YAML-Codes ohne Anker und Aliase: ```yaml jobs: job1: env: NODE_ENV: production DATABASE_URL: ${{ secrets.DATABASE_URL }} steps: - run: echo "Using production settings" job2: env: NODE_ENV: production DATABASE_URL: ${{ secrets.DATABASE_URL }} steps: - run: echo "Same environment variables here" ``` Du kannst Anker außerdem für komplexere Konfigurationen wie die Wiederverwendung einer gesamten Auftragskonfiguration verwenden: ```yaml jobs: test: &base_job # Define the anchor on first use runs-on: ubuntu-latest timeout-minutes: 30 env: NODE_VERSION: '18' steps: - uses: actions/checkout@v6 - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} - run: npm test alt-test: *base_job # Reuse the entire job configuration ```