> \[!NOTE]
> Du kannst Docker-Container-, JavaScript- und zusammengesetzte Aktionen erstellen. Aktionen erfordern eine Metadatendatei, um die Eingaben, Ausgaben und Ausführungskonfigurationen für deine Aktion zu definieren. Metadatendateien für Aktionen verwenden YAML-Syntax, und der Name der Metadatendatei muss `action.yml` oder `action.yaml` lauten. Das bevorzugte Format ist `action.yml`.

## `name`

**Erforderlich** Der Name deiner Aktion. GitHub zeigt `name` auf der Registerkarte **Aktionen** an, damit Aktionen in jedem Auftrag erkennbar sind.

## `author`

**Optional** Der Name des Autors der Aktion

## `description`

**Erforderlich** Eine kurze Beschreibung der Aktion

## `inputs`

**Optional** Mit Eingabeparametern kannst du die Daten angeben, die die Aktion während der Laufzeit erwartet. GitHub speichert Eingabeparameter als Umgebungsvariablen. Du solltest Eingabe-IDs in Kleinbuchstaben verwenden.

### Beispiel: Angeben von Eingaben

In diesem Beispiel werden zwei Eingaben konfiguriert: `num-octocats` und `octocat-eye-color`. Die Eingabe `num-octocats` ist nicht erforderlich und wird standardmäßig auf den Wert `1` festgelegt. `octocat-eye-color` ist erforderlich und weist keinen Standardwert auf.

> \[!NOTE]
> Aktionen, die `required: true` verwenden, geben nicht automatisch einen Fehler zurück, wenn keine Eingabe angegeben ist.

Workflowdateien, die diese Aktion nutzen, müssen das Schlüsselwort `with` verwenden, um einen Eingabewert für `octocat-eye-color` festzulegen. Weitere Informationen zur `with`-Syntax findest du unter [Workflowsyntax für GitHub Actions](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith).

```yaml
inputs:
  num-octocats:
    description: 'Number of Octocats'
    required: false
    default: '1'
  octocat-eye-color:
    description: 'Eye color of the Octocats'
    required: true
```

Wenn Sie eine Eingabe angeben, erstellt GitHub eine Umgebungsvariable für die Eingabe mit dem Namen `INPUT_<VARIABLE_NAME>`. Die erstellte Umgebungsvariable konvertiert Eingabenamen in Großbuchstaben und ersetzt Leerzeichen durch `_`-Zeichen.

Wenn es sich um eine [zusammengesetzte](/de/actions/creating-actions/creating-a-composite-action) Aktion handelt, wird `INPUT_<VARIABLE_NAME>` nicht automatisch erstellt. Mit zusammengesetzten Aktionen können Sie `inputs` [Kontextreferenz](/de/actions/learn-github-actions/contexts) verwenden, um auf Aktionseingaben zuzugreifen.

Um auf die Umgebungsvariable in einer Docker-Containeraktion zuzugreifen, musst du die Eingabe mithilfe des Schlüsselworts `args` in der Metadatendatei für die Aktion übergeben. Weitere Informationen zur Metadatendatei für Docker-Containeraktionen findest du unter [Creating a Docker container action (Erstellen einer Docker-Containeraktion)](/de/actions/creating-actions/creating-a-docker-container-action#creating-an-action-metadata-file).

Wenn ein Workflow beispielsweise die Eingaben `num-octocats` und `octocat-eye-color` definiert hat, kann der Aktionscode die Werte der Eingaben mithilfe der Umgebungsvariablen `INPUT_NUM-OCTOCATS` und `INPUT_OCTOCAT-EYE-COLOR` lesen.

### `inputs.<input_id>`

**Erforderlich** Ein `string`-Bezeichner, der der Eingabe zugeordnet werden soll. Der Wert von `<input_id>` entspricht einer Zuordnung der Metadaten der Eingabe. `<input_id>` muss ein eindeutiger Bezeichner innerhalb des `inputs`-Objekts sein. `<input_id>` muss mit einem Buchstaben oder `_` beginnen und darf nur alphanumerische Zeichen, `-` oder `_` enthalten.

### `inputs.<input_id>.description`

**Erforderlich** Eine `string`-Beschreibung des Eingabeparameters

### `inputs.<input_id>.required`

**Optional** Ein `boolean`-Wert, der angibt, ob die Aktion den Eingabeparameter benötigt. Dieser ist auf `true` festgelegt, wenn der Parameter erforderlich ist.

### `inputs.<input_id>.default`

**Optional** Ein `string`-Wert, der den Standardwert darstellt. Der Standardwert wird verwendet, wenn ein Eingabeparameter in einer Workflow-Datei nicht angegeben ist.

### `inputs.<input_id>.deprecationMessage`

**Optional** Wenn der Eingabeparameter verwendet wird, wird dieser `string`-Wert als Warnmeldung protokolliert. Du kannst diese Warnung verwenden, um Benutzer\*innen darüber zu informieren, dass die Eingabe closing down ist, und mögliche Alternativen erwähnen.

## `outputs` für Docker-Containeraktionen und JavaScript-Aktionen

**Optional** Ausgabeparameter ermöglichen es Ihnen, Daten zu deklarieren, die eine Aktion festlegt. Aktionen, die in einem Workflow später ausgeführt werden, können die Ausgabedaten der zuvor ausgeführten Aktionen verwenden. Wenn beispielsweise eine Aktion vorliegt, die zwei Eingaben addiert hat (x + y = z), kann die Aktion die Summe (z) für andere Aktionen ausgeben, damit sie dort als Eingabe verwendet wird.

Ausgaben dürfen maximal 1 MB pro Auftrag groß sein. Die Gesamtanzahl aller Ausgaben in einer Workflowausführung kann maximal 50 MB betragen. Eine Annäherung an die Größe erfolgt auf Basis der UTF-16-Codierung.

Auch wenn du in der Metadaten-Datei deiner Aktion keine Ausgabe deklarierst, kannst du dennoch Ausgaben festlegen und in einem Workflow verwenden. Weitere Informationen zum Festlegen von Ausgaben in einer Aktion findest du unter [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter).

### Beispiel: Deklarieren von Ausgaben für Docker-Containeraktionen und JavaScript-Aktionen

```yaml
outputs:
  sum: # id of the output
    description: 'The sum of the inputs'
```

### `outputs.<output_id>`

**Erforderlich** Ein `string`-Bezeichner, der der Ausgabe zugeordnet werden soll. Der Wert von `<output_id>` entspricht einer Zuordnung der Metadaten der Ausgabe. `<output_id>` muss ein eindeutiger Bezeichner innerhalb des `outputs`-Objekts sein. `<output_id>` muss mit einem Buchstaben oder `_` beginnen und darf nur alphanumerische Zeichen, `-` oder `_` enthalten.

### `outputs.<output_id>.description`

**Erforderlich** Eine `string`-Beschreibung des Ausgabeparameters

## `outputs` für zusammengesetzte Aktionen

**Optional** `outputs` verwendet die gleichen Parameter wie `outputs.<output_id>` und `outputs.<output_id>.description` ([`outputs` für Docker-Containeraktionen und JavaScript-Aktionen](#outputs-for-docker-container-and-javascript-actions)), enthält jedoch das Token `value`.

Ausgaben dürfen maximal 1 MB pro Auftrag groß sein. Die Gesamtanzahl aller Ausgaben in einer Workflowausführung kann maximal 50 MB betragen. Eine Annäherung an die Größe erfolgt auf Basis der UTF-16-Codierung.

### Beispiel: Deklarieren von Ausgaben für zusammengesetzte Aktionen

```yaml
outputs:
  random-number:
    description: "Random number"
    value: ${{ steps.random-number-generator.outputs.random-id }}
runs:
  using: "composite"
  steps:
    - id: random-number-generator
      run: echo "random-id=$(echo $RANDOM)" >> $GITHUB_OUTPUT
      shell: bash
```

### `outputs.<output_id>.value`

**Erforderlich** Der Wert, dem der Ausgabeparameter zugeordnet wird. Du kannst diesen auf `string` oder einen Ausdruck mit Kontext festlegen. Du kannst beispielsweise den `steps`-Kontext verwenden, um das `value`-Element einer Ausgabe auf den Ausgabewert eines Schritts festzulegen.

Weitere Informationen zur Verwendung der Kontextsyntax findest du unter [Kontextreferenz](/de/actions/learn-github-actions/contexts).

## `runs`

**Erforderlich** Gibt an, ob es sich um eine JavaScript-Aktion, eine zusammengesetzte Aktion oder eine Docker-Containeraktion handelt und wie die Aktion ausgeführt wird

## `runs` für JavaScript-Aktionen

**Erforderlich** Konfiguriert den Pfad zum Code der Aktion und die Runtime, die zum Ausführen des Codes verwendet wird

### Beispiel: Verwendung von Node.js 24

```yaml
runs:
  using: 'node24'
  main: 'main.js'
```

### `runs.using` für JavaScript-Aktionen

**Erforderlich** Die Runtime, mit der der in [`main`](#runsmain) angegebene Code ausgeführt wird.

* Verwende `node20` für Node.js v20.
* Verwende `node24` für Node.js 24.

### `runs.main`

**Erforderlich** Die Datei, die deinen Aktionscode enthält. Die in [`using`](#runsusing-for-javascript-actions) angegebene Runtime führt diese Datei aus.

### `runs.pre`

**Optional** Ermöglicht es Ihnen, ein Skript am Anfang eines Auftrags auszuführen, bevor die Aktion `main:` beginnt. Du kannst beispielsweise mit `pre:` ein erforderliches Setupskript ausführen. Die mit der [`using`](#runsusing-for-javascript-actions)-Syntax angegebene Runtime führt diese Datei aus. Die Aktion `pre:` wird standardmäßig immer ausgeführt. Du kannst dies jedoch mit [`runs.pre-if`](#runspre-if) außer Kraft setzen.

> \[!NOTE]
> `runs.pre` wird für lokale Aktionen nicht unterstützt.

In diesem Beispiel führt die Aktion `pre:` ein Skript mit dem Namen `setup.js` aus:

```yaml
runs:
  using: 'node24'
  pre: 'setup.js'
  main: 'index.js'
  post: 'cleanup.js'
```

### `runs.pre-if`

**Optional** Ermöglicht es Ihnen, Bedingungen für die Ausführung der Aktion `pre:` zu definieren. Die Aktion `pre:` wird nur ausgeführt, wenn die Bedingungen in `pre-if` erfüllt sind. Wenn keine festgelegt sind, wird `pre-if` standardmäßig auf `always()` festgelegt. In `pre-if` vergleichen die entsprechenden Funktionen den Status mit dem des Auftrags, nicht mit dem Status der Aktion.

Beachte, dass der `step`-Kontext nicht verfügbar ist, da noch keine Schritte ausgeführt wurden.

In diesem Beispiel kann `cleanup.js` nur mit Linux-basierten Runnern ausgeführt werden.

```yaml
  pre: 'cleanup.js'
  pre-if: runner.os == 'linux'
```

### `runs.post`

**Optional** Ermöglicht es Ihnen, ein Skript am Ende eines Auftrags auszuführen, sobald die Aktion `main:` abgeschlossen wurde. Du kannst beispielsweise `post:` verwenden, um bestimmte Prozesse zu beenden oder nicht benötigte Dateien zu entfernen. Die mit der [`using`](#runsusing-for-javascript-actions)-Syntax angegebene Runtime führt diese Datei aus.

In diesem Beispiel führt die Aktion `post:` ein Skript mit dem Namen `cleanup.js` aus:

```yaml
runs:
  using: 'node24'
  main: 'index.js'
  post: 'cleanup.js'
```

Die Aktion `post:` wird standardmäßig immer ausgeführt. Du kannst dies jedoch mit `post-if` außer Kraft setzen.

### `runs.post-if`

**Optional** Ermöglicht es Ihnen, Bedingungen für die Ausführung der Aktion `post:` zu definieren. Die Aktion `post:` wird nur ausgeführt, wenn die Bedingungen in `post-if` erfüllt sind. Wenn keine festgelegt sind, wird `post-if` standardmäßig auf `always()` festgelegt. In `post-if` vergleichen die entsprechenden Funktionen den Status mit dem des Auftrags, nicht mit dem Status der Aktion.

`cleanup.js` kann beispielsweise nur mit Linux-basierten Runnern ausgeführt werden:

```yaml
  post: 'cleanup.js'
  post-if: runner.os == 'linux'
```

## `runs` für zusammengesetzte Aktionen

**Erforderlich** Konfiguriert den Pfad zur zusammengesetzten Aktion

### `runs.using` für zusammengesetzte Aktionen

**Erforderlich** Du musst diesen Wert auf `'composite'` festlegen.

### `runs.steps`

**Erforderlich** Die Schritte, die in dieser Aktion ausgeführt werden sollen. Dabei kann es sich um `run`- oder `uses`-Schritte handeln.

#### `runs.steps[*].run`

**Optional** Der Befehl, den du ausführen möchtest. Dieser kann inline oder mit einem Skript in deinem Aktionsrepository angegeben werden:

```yaml
runs:
  using: "composite"
  steps:
    - run: ${{ github.action_path }}/test/script.sh
      shell: bash
```

Alternativ kannst du auch `$GITHUB_ACTION_PATH` verwenden:

```yaml
runs:
  using: "composite"
  steps:
    - run: $GITHUB_ACTION_PATH/script.sh
      shell: bash
```

Weitere Informationen finden Sie unter [Kontextreferenz](/de/actions/learn-github-actions/contexts#github-context).

#### `runs.steps[*].shell`

**Optional** Die Shell, in der der Befehl ausgeführt werden soll. Du kannst eine der in [Workflowsyntax für GitHub Actions](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell) aufgeführten Shells verwenden. Erforderlich, wenn `run` festgelegt ist.

#### `runs.steps[*].if`

**Optional** Du kannst die `if`-Bedingung verwenden, um zu verhindern, dass ein Schritt ausgeführt wird – es sei denn, eine Bedingung ist erfüllt. Du kannst eine Bedingung mit jedem unterstützten Kontext und Ausdruck erstellen.

Wenn du Ausdrücke in einer `if`-Bedingung verwendest, kannst du optional die `${{ }}`-Ausdruckssyntax weglassen, da GitHub Actions die `if`-Bedingung automatisch als Ausdruck wertet. Diese Ausnahme gilt jedoch nicht überall.

Du musst immer die Syntax des `${{ }}`-Ausdrucks verwenden oder mit `''`, `""` oder `()` abbrechen, wenn der Ausdruck mit `!` beginnt, da `!` die reservierte Schreibweise im YAML-Format ist. Zum Beispiel:

```yaml
if: ${{ ! startsWith(github.ref, 'refs/tags/') }}
```

Weitere Informationen findest du unter [Auswerten von Ausdrücken in Workflows und Aktionen](/de/actions/learn-github-actions/expressions).

**Beispiel: Verwenden von Kontexten**

Dieser Schritt wird nur ausgeführt, wenn der Ereignistyp `pull_request` und die Ereignisaktion `unassigned` lautet.

```yaml
steps:
  - run: echo This event is a pull request that had an assignee removed.
    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
```

**Beispiel: Verwenden von Funktionen zur Statusüberprüfung**

`my backup step` wird nur ausgeführt, wenn der vorherige Schritt einer zusammengesetzten Aktion nicht erfolgreich war. Weitere Informationen finden Sie unter [Auswerten von Ausdrücken in Workflows und Aktionen](/de/actions/learn-github-actions/expressions#status-check-functions).

```yaml
steps:
  - name: My first step
    uses: octo-org/action-name@main
  - name: My backup step
    if: ${{ failure() }}
    uses: actions/heroku@1.0.0
```

#### `runs.steps[*].name`

**Optional** Der Name des zusammengesetzten Schritts

#### `runs.steps[*].id`

**Optional** Ein eindeutiger Bezeichner für den Schritt. Du kannst mit `id` auf den Schritt in Kontexten verweisen. Weitere Informationen finden Sie unter [Kontextreferenz](/de/actions/learn-github-actions/contexts).

#### `runs.steps[*].env`

**Optional** Legt `map` für Umgebungsvariablen fest, die nur für diesen Schritt vorgesehen sind. Wenn du die im Workflow gespeicherte Umgebungsvariable ändern möchtest, verwende `echo "{name}={value}" >> $GITHUB_ENV` in einem zusammengesetzten Schritt.

#### `runs.steps[*].working-directory`

**Optional** Gibt das Arbeitsverzeichnis an, in dem der Befehl ausgeführt wird

#### `runs.steps[*].uses`

**Optional** Wählt eine Aktion aus, die als Teil eines Schritts in deinem Auftrag ausgeführt werden soll. Eine Aktion ist eine wiederverwendbare Code-Einheit. Du kannst eine Aktion verwenden, die im selben Repository wie der Workflow, in einem öffentlichen Repository oder in einem [veröffentlichten Docker-Containerimage](http://hub.docker.com/) definiert ist.

Es wird dringend empfohlen, die verwendete Version der Aktion zu nennen (Git-Ref, SHA oder Docker-Tag-Nummer angeben). Wenn du keine Version angibst, könnten damit die Workflows gestört werden, oder es wird ein unerwartetes Verhalten hervorgerufen, wenn der bzw. die Besitzer\*in der Aktion eine Aktualisierung veröffentlicht.

* Am besten in Hinblick auf Stabilität und Sicherheit ist es, die Commit-SHA einer freigegebenen Version einer Aktion zu verwenden.
* Wenn du dich auf die Hauptversion der Aktion beziehst, kannst du kritische Fehlerbehebungen und Sicherheitspatches erhalten und gleichzeitig die Kompatibilität wahren. Außerdem ist damit sichergestellt, dass der Workflow weiterhin problemlos arbeiteten sollte.
* Die Verwendung des Standardbranches einer Aktion ist zwar auf den ersten Blick praktisch, doch wenn eine neue Hauptversion mit einem Breaking Change veröffentlicht wird, könnte der Workflow unterbrochen werden.

Einige Aktionen erfordern Eingaben, die du mit dem Schlüsselwort [`with`](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith) festlegen musst. Die erforderlichen Eingaben findest du in der README-Datei der Aktion.

```yaml
runs:
  using: "composite"
  steps:
    # Reference a specific commit
    - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
    # Reference the major version of a release
    - uses: actions/checkout@v5
    # Reference a specific version
    - uses: actions/checkout@v5.2.0
    # Reference a branch
    - uses: actions/checkout@main
    # References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA
    - uses: actions/aws/ec2@main
    # References a local action
    - uses: ./.github/actions/my-action
    # References a docker public registry action
    - uses: docker://gcr.io/cloud-builders/gradle
    # Reference a docker image published on docker hub
    - uses: docker://alpine:3.8
```

#### `runs.steps[*].with`

**Optional** Eine `map` der Eingabeparameter, die durch die Aktion definiert werden. Jeder Eingabeparameter ist ein Schlüssel-Wert-Paar. Weitere Informationen findest du unter [Beispiel: Angeben von Eingaben](#example-specifying-inputs).

```yaml
runs:
  using: "composite"
  steps:
    - name: My first step
      uses: actions/hello_world@main
      with:
        first_name: Mona
        middle_name: The
        last_name: Octocat
```

#### `runs.steps[*].continue-on-error`

**Optional** Verhindert, dass bei der Aktion ein Fehler auftritt, wenn bei einem Schritt ein Fehler auftritt. Lege dies auf `true` fest, damit die Aktion erfolgreich abgeschlossen werden kann, wenn bei diesem Schritt ein Fehler auftritt.

## `runs` für Docker-Containeraktionen

**Erforderlich** Konfiguriert das Image, das für die Docker-Containeraktion verwendet wird

### Beispiel: Verwenden eines Dockerfiles in deinem Repository

```yaml
runs:
  using: 'docker'
  image: 'Dockerfile'
```

### Beispiel: Verwenden des öffentlichen Docker-Registrierungscontainers

```yaml
runs:
  using: 'docker'
  image: 'docker://debian:stretch-slim'
```

### `runs.using` für Docker-Containeraktionen

**Erforderlich** Du musst diesen Wert auf `'docker'` festlegen.

### `runs.pre-entrypoint`

**Optional** Ermöglicht es Ihnen, ein Skript auszuführen, bevor die Aktion `entrypoint` beginnt. Du kannst beispielsweise mit `pre-entrypoint:` ein erforderliches Setupskript ausführen. GitHub Actions verwendet `docker run`, um diese Aktion zu starten, und führt das Skript in einem neuen Container aus, der das gleiche Basisimage verwendet. Das bedeutet, dass sich der Laufzeitstatus vom `entrypoint`-Hauptcontainer unterscheidet, und auf alle benötigten Status muss entweder im Arbeitsbereich `HOME` oder als `STATE_`-Variable zugegriffen werden. Die Aktion `pre-entrypoint:` wird standardmäßig immer ausgeführt. Du kannst dies jedoch mit [`runs.pre-if`](#runspre-if) außer Kraft setzen.

Die mit der [`using`](#runsusing-for-docker-container-actions)-Syntax angegebene Runtime führt diese Datei aus.

In diesem Beispiel führt die Aktion `pre-entrypoint:` ein Skript mit dem Namen `setup.sh` aus:

```yaml
runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - 'bzz'
  pre-entrypoint: 'setup.sh'
  entrypoint: 'main.sh'
```

### `runs.image`

**Erforderlich** Docker-Image, das beim Ausführen der Aktion als Container herangezogen wird. Der Wert kann der Name des Docker-Basisimages sein, ein lokales `Dockerfile` in deinem Repository oder ein öffentliches Image in Docker Hub oder einer anderen Registrierung. Damit du lokal auf ein `Dockerfile` in deinem Repository verweisen kannst, muss die Datei `Dockerfile` heißen, und du musst einen relativen Pfad zu deiner Metadatendatei für die Aktion verwenden. Die `docker`-Anwendung führt diese Datei aus.

### `runs.env`

**Optional** Gibt eine Schlüssel-Wert-Zuordnung der Umgebungsvariablen an, die in der Containerumgebung festgelegt werden sollen.

### `runs.entrypoint`

**Optional** Überschreibt `ENTRYPOINT` für Docker in `Dockerfile` oder legt einen Einstiegspunkt fest, falls noch keiner vorhanden ist. Verwende `entrypoint`, wenn `ENTRYPOINT` in `Dockerfile` nicht angegeben ist oder du die `ENTRYPOINT`-Anweisung außer Kraft setzen möchtest. Wenn du `entrypoint` auslässt, werden die Befehle ausgeführt, die du in der Docker-Anweisung `ENTRYPOINT` angibst. Für die Docker-Anweisung `ENTRYPOINT` gibt es ein *Shellformat* und ein *Ausführungsformat*. In der Docker-Dokumentation zu `ENTRYPOINT` wird das *Ausführungsformat* der `ENTRYPOINT`-Anweisung empfohlen.

Weitere Informationen zur Ausführung von `entrypoint` findest du unter [Dockerfile Unterstützung für GitHub Aktionen](/de/actions/creating-actions/dockerfile-support-for-github-actions#entrypoint).

### `runs.post-entrypoint`

**Optional** Ermöglicht es Ihnen, ein Bereinigungsskript auszuführen, sobald die Aktion `runs.entrypoint` abgeschlossen ist. GitHub Actions verwendet `docker run`, um diese Aktion zu starten. Da GitHub Actions das Skript in einem neuen Container mit dem gleichen Basisimage ausführt, unterscheidet sich der Laufzeitstatus vom `entrypoint`-Hauptcontainer. Du kannst auf jeden benötigten Status im Arbeitsbereich `HOME` oder als `STATE_`-Variable zugreifen. Die Aktion `post-entrypoint:` wird standardmäßig immer ausgeführt. Du kannst dies jedoch mit [`runs.post-if`](#runspost-if) außer Kraft setzen.

```yaml
runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - 'bzz'
  entrypoint: 'main.sh'
  post-entrypoint: 'cleanup.sh'
```

### `runs.args`

**Optional** Ein Array aus Zeichenfolgen, die die Eingaben für einen Docker-Container definieren. Eingaben können hartcodierte Strings enthalten. GitHub übergibt `args` beim Start des Containers an dessen `ENTRYPOINT`.

Die `args`-Elemente werden anstelle der `CMD`-Anweisung in `Dockerfile` verwendet. Wenn du `CMD` in `Dockerfile` verwendest, befolge diese Hinweise (nach Präferenz sortiert):

1. Dokumentieren die erforderlichen Argumente in der README-Datei der Aktion, und lasse sie in der `CMD`-Anweisung weg.
2. Verwende Standardwerte, die die Verwendung der Aktion ohne die Angabe von `args` ermöglichen.
3. Wenn die Aktion ein `--help`-Flag oder etwas ähnliches verfügbar macht, verwende dies, damit die Aktion selbstdokumentierend wird.

Wenn du Umgebungsvariablen an eine Aktion übergeben musst, stelle sicher, dass deine Aktion eine Kommando-Shell ausführt, damit die Variablen ausgewertet werden. Wenn dein `entrypoint`-Attribut beispielsweise auf `"sh -c"` festgelegt ist, wird `args` in einer Befehlsshell ausgeführt. Wenn `Dockerfile` jedoch `ENTRYPOINT` für die Ausführung dieses Befehls (`"sh -c"`) verwendet, wird `args` in einer Befehlsshell ausgeführt.

Weitere Informationen zur Verwendung der `CMD`-Anweisung mit GitHub Actions findest du unter [Dockerfile Unterstützung für GitHub Aktionen](/de/actions/creating-actions/dockerfile-support-for-github-actions#cmd).

#### Beispiel: Definieren von Argumenten für den Docker-Container

```yaml
runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - ${{ inputs.greeting }}
    - 'foo'
    - 'bar'
```

## `branding`

**Optional:** Du kannst ein farbiges [Feather](http://feathericons.com/)-Symbol verwenden, um einen personalisierten Badge für deine Aktion zu erstellen. Badges werden neben dem Aktionsnamen in [GitHub Marketplace](http://github.com/marketplace?type=actions) angezeigt.

### Beispiel: Konfigurieren des Brandings für eine Aktion

```yaml
branding:
  icon: 'award'
  color: 'green'
```

### `branding.color`

Die Hintergrundfarbe des Badges Dies kann eine der folgenden Möglichkeiten sein: `white`, `black`, `yellow`, `blue`, `green`, `orange`, `red`, `purple` oder `gray-dark`.

### `branding.icon`

Der Name des zu verwendenden [Feather-Symbols](http://feathericons.com/) (Version 4.28.0).

#### Ausgelassene Symbole

Markensymbole und alle folgenden Symbole werden weggelassen:

<ul style="-webkit-column-count: 4; -moz-column-count: 4; column-count: 4;">
<li>Kaffee</li>
<li>Spalten</li>
<li>divide-circle</li>
<li>divide-square</li>
<li>divide</li>
<li>frown</li>
<li>Hexagon</li>
<li>Schlüssel</li>
<li>meh</li>
<li>mouse-pointer</li>
<li>smile</li>
<li>Tool</li>
<li>x-octagon</li>
</ul>

#### Vollständige Liste aller derzeit unterstützten Symbole:

<!--
  This list should match the icon list in `app/models/repository_actions/icons.rb` in the internal github repo.
  To support a new icon, update `app/models/repository_actions/icons.rb` and add the svg to `/static/images/icons/feather` in the internal github repo.
-->

<ul style="-webkit-column-count: 4; -moz-column-count: 4; column-count: 4;">
<li>activity</li>
<li>airplay</li>
<li>alert-circle</li>
<li>alert-octagon</li>
<li>alert-triangle</li>
<li>align-center</li>
<li>align-justify</li>
<li>align-left</li>
<li>align-right</li>
<li>Anker</li>
<li>aperture</li>
<li>archive</li>
<li>arrow-down-circle</li>
<li>arrow-down-left</li>
<li>arrow-down-right</li>
<li>arrow-down</li>
<li>arrow-left-circle</li>
<li>arrow-left</li>
<li>arrow-right-circle</li>
<li>arrow-right</li>
<li>arrow-up-circle</li>
<li>arrow-up-left</li>
<li>arrow-up-right</li>
<li>Pfeil-hoch</li>
<li>at-sign</li>
<li>award</li>
<li>bar-chart-2</li>
<li>bar-chart</li>
<li>battery-charging</li>
<li>battery</li>
<li>bell-off</li>
<li>Glocke</li>
<li>Bluetooth</li>
<li>fett</li>
<li>book-open</li>
<li>book (Buch)</li>
<li>Lesezeichen (bookmark)</li>
<li>box</li>
<li>briefcase</li>
<li>Kalender</li>
<li>camera-off</li>
<li>Kamera</li>
<li>Umwandlung</li>
<li>check-circle</li>
<li>check-square</li>
<li>Häkchen</li>
<li>chevron-down</li>
<li>chevron-left</li>
<li>chevron-right</li>
<li>chevron-up</li>
<li>chevrons-down</li>
<li>chevrons-left</li>
<li>chevrons-right</li>
<li>chevrons-up</li>
<li>circle</li>
<li>Zwischenablage</li>
<li>clock</li>
<li>cloud-drizzle</li>
<li>cloud-lightning</li>
<li>cloud-off</li>
<li>cloud-rain</li>
<li>cloud-snow</li>
<li>cloud</li>
<li>code</li>
<li>command</li>
<li>compass</li>
<li>copy</li>
<li>corner-down-left</li>
<li>corner-down-right</li>
<li>corner-left-down</li>
<li>corner-left-up</li>
<li>corner-right-down</li>
<li>corner-right-up</li>
<li>corner-up-left</li>
<li>corner-up-right</li>
<li>cpu</li>
<li>credit-card</li>
<li>crop</li>
<li>crosshair</li>
<li>database</li>
<li>delete</li>
<li>disc</li>
<li>dollar-sign</li>
<li>download-cloud</li>
<li>Download verfügbar ist</li>
<li>droplet</li>
<li>edit-2</li>
<li>edit-3</li>
<li>Bearbeiten</li>
<li>external-link</li>
<li>eye-off</li>
<li>eye</li>
<li>Fast-Forward</li>
<li>feather</li>
<li>file-minus</li>
<li>file-plus</li>
<li>file-text</li>
<li>file</li>
<li>film</li>
<li>filter</li>
<li>Flag</li>
<li>folder-minus</li>
<li>folder-plus</li>
<li>folder</li>
<li>gift</li>
<li>git-branch</li>
<li>git-commit</li>
<li>git-merge</li>
<li>git-pull-request</li>
<li>globe</li>
<li>grid</li>
<li>hard-drive</li>
<li>hash</li>
<li>headphones</li>
<li>herzlich</li>
<li>help-circle</li>
<li>home</li>
<li>image</li>
<li>inbox</li>
<li>info</li>
<li>kursiv</li>
<li>Ebenen</li>
<li>Layout</li>
<li>life-buoy</li>
<li>link-2</li>
<li>link</li>
<li>list</li>
<li>loader</li>
<li>Sperre</li>
<li>log-in</li>
<li>log-out</li>
<li>mail</li>
<li>map-pin</li>
<li>Karte</li>
<li>maximize-2</li>
<li>maximize</li>
<li>Menü</li>
<li>message-circle</li>
<li>message-square</li>
<li>mic-off</li>
<li>mic</li>
<li>minimize-2</li>
<li>minimize</li>
<li>minus-circle</li>
<li>minus-square</li>
<li>minus</li>
<li>Überwachen</li>
<li>moon</li>
<li>more-horizontal</li>
<li>more-vertical</li>
<li>Verschieben</li>
<li>music</li>
<li>navigation-2</li>
<li>navigation</li>
<li>octagon</li>
<li>Paket</li>
<li>paperclip</li>
<li>pause-circle</li>
<li>pause</li>
<li>Prozent</li>
<li>phone-call</li>
<li>phone-forwarded</li>
<li>phone-incoming</li>
<li>phone-missed</li>
<li>phone-off</li>
<li>phone-outgoing</li>
<li>phone</li>
<li>pie-chart</li>
<li>play-circle</li>
<li>play</li>
<li>plus-circle</li>
<li>plus-square</li>
<li>plus</li>
<li>pocket</li>
<li>power</li>
<li>printer</li>
<li>radio</li>
<li>refresh-ccw</li>
<li>refresh-cw</li>
<li>wiederholen</li>
<li>rewind</li>
<li>rotate-ccw</li>
<li>rotate-cw</li>
<li>rss</li>
<li>Speichern</li>
<li>scissors</li>
<li>search</li>
<li>Send</li>
<li>server</li>
<li>settings</li>
<li>share-2</li>
<li>Freigeben</li>
<li>shield-off</li>
<li>shield</li>
<li>shopping-bag</li>
<li>shopping-cart</li>
<li>Shuffle</li>
<li>sidebar</li>
<li>skip-back</li>
<li>skip-forward</li>
<li>slash</li>
<li>Schieberegler</li>
<li>smartphone</li>
<li>Lautsprecher</li>
<li>square</li>
<li>Sternchen</li>
<li>stop-circle</li>
<li>sun</li>
<li>sunrise</li>
<li>Sonnenuntergang</li>
<li>table</li>
<li>Tablet</li>
<li>das Tag</li>
<li>target</li>
<li>terminal</li>
<li>thermometer</li>
<li>thumbs-down</li>
<li>thumbs-up</li>
<li>toggle-left</li>
<li>toggle-right</li>
<li>trash-2</li>
<li>trash</li>
<li>trending-down</li>
<li>trending-up</li>
<li>Dreieck</li>
<li>LKW</li>
<li>tv</li>
<li>type</li>
<li>Regenschirm</li>
<li>Unterstrichen</li>
<li>Entsperren</li>
<li>upload-cloud</li>
<li>upload</li>
<li>user-check</li>
<li>user-minus</li>
<li>user-plus</li>
<li>user-x</li>
<li>user</li>
<li>users</li>
<li>video-off</li>
<li>video</li>
<li>voicemail</li>
<li>volume-1</li>
<li>volume-2</li>
<li>volume-x</li>
<li>Volume</li>
<li>watch</li>
<li>wifi-off</li>
<li>wifi</li>
<li>wind</li>
<li>x-circle</li>
<li>x-square</li>
<li>x</li>
<li>zap-off</li>
<li>zap</li>
<li>zoom-in</li>
<li>zoom-out</li>
</ul>

## Ändern des Namens der Metadatendatei

Während die Aktionsmetadatendatei beide YAML-Formate unterstützt, wirkt sich das Ändern des Namens der Metadatendatei (von `action.yml` zu `action.yaml` oder umgekehrt) zwischen Versionen auf frühere Releaseversionen aus, die im GitHub Marketplace veröffentlicht wurden. Durch das Ändern des Dateinamens werden alle Releaseversionen im GitHub Marketplace ausgeblendet, die dem vorherigen Dateinamen zugeordnet sind. Auf frühere Releaseversionen kann weiterhin über das Quellrepository zugegriffen werden.

Bei der Veröffentlichung neuer Versionen von Aktionen besitzen nur Versionen nach der Änderung des Metadatendateinamens das GitHub Marketplace-Tag und werden auf GitHub Marketplace
angezeigt.