Diese Version von GitHub Enterprise wurde eingestellt am 2021-09-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Finding and customizing actions

Actions are the building blocks that power your workflow. A workflow can contain actions created by the community, or you can create your own actions directly within your application's repository. This guide will show you how to discover, use, and customize actions.

Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.

Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.


The actions you use in your workflow can be defined in:

  • Ein öffentliches Repository
  • The same repository where your workflow file references the action
  • Ein veröffentlichtes Docker-Containerimage auf Docker Hub

GitHub Marketplace is a central location for you to find actions created by the GitHub community.

Note: GitHub Actions on your GitHub Enterprise Server instance may have limited access to actions on GitHub.com or GitHub Marketplace. Weitere Informationen findest Du unter „Kommunikation zwischen selbst-gehosteten Runnern und GitHub“.

Using release management for your custom actions

The creators of a community action have the option to use tags, branches, or SHA values to manage releases of the action. Similar to any dependency, you should indicate the version of the action you'd like to use based on your comfort with automatically accepting updates to the action.

You will designate the version of the action in your workflow file. Check the action's documentation for information on their approach to release management, and to see which tag, branch, or SHA value to use.

Note: We recommend that you use a SHA value when using third-party actions. For more information, see Security hardening for GitHub Actions

Using tags

Tags are useful for letting you decide when to switch between major and minor versions, but these are more ephemeral and can be moved or deleted by the maintainer. This example demonstrates how to target an action that's been tagged as v1.0.1:

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

Using SHAs

If you need more reliable versioning, you should use the SHA value associated with the version of the action. SHAs are immutable and therefore more reliable than tags or branches. However this approach means you will not automatically receive updates for an action, including important bug fixes and security updates. This example targets an action's SHA:

  - uses: actions/javascript-action@172239021f7ba04fe7327647b213799853a9eb89

Using branches

Specifying a target branch for the action means it will always run the version currently on that branch. This approach can create problems if an update to the branch includes breaking changes. This example targets a branch named @main:

  - uses: actions/javascript-action@main

For more information, see "Using release management for actions."

Using inputs and outputs with an action

An action often accepts or requires inputs and generates outputs that you can use. For example, an action might require you to specify a path to a file, the name of a label, or other data it will use as part of the action processing.

To see the inputs and outputs of an action, check the action.yml or action.yaml in the root directory of the repository.

In this example action.yml, the inputs keyword defines a required input called file-path, and includes a default value that will be used if none is specified. The outputs keyword defines an output called results-file, which tells you where to locate the results.

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

Verweisen auf eine Aktion im selben Repository, in dem eine Workflowdatei die Aktion verwendet

Wenn eine Aktion im selben Repository definiert ist, in dem Ihre Workflowdatei die Aktion verwendet, können Sie auf die Aktion mit der{owner}/{repo}-{ref} oder ./path/to/dir- Syntax in ihrer Workflowdatei verweisen.


|-- hello-world (Repository)
|   |__ .github
|       Workflows
|           My-First-Workflow.yml
|       • Maßnahmen
|           |__ hello-world-action
|               • action.yml


    läuft auf: ubuntu-latest
      - Dieser Schritt checkt eine Kopie Ihres Repositorys aus.
      - verwendet: actions/checkout@v2
      - Dieser Schritt verweist auf das Verzeichnis, das die Aktion enthält.
      - verwendet: ./.github/actions/hello-world-action

The action.yml file is used to provide metadata for the action. Learn about the content of this file in "Metadata syntax for GitHub Actions"

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 docker://{image}:{tag} Syntax in Ihrer Workflowdatei verweisen. Zum Schutz Ihres Codes und Ihrer Daten wird dringend empfohlen, die Integrität des Docker-Containerimages von Docker Hub zu überprüfen, bevor Sie es in Ihrem Workflow verwenden.

      - Name: Mein erster Schritt
        verwendet: docker://alpine:3.8

Einige Beispiele für Docker-Aktionen finden Sie im Docker-image.yml-Workflow oder unter „Eine Docker-Container-Aktion erstellen“.

Nächste Schritte:

To continue learning about GitHub Actions, see "Essential features of GitHub Actions."