Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-03-26. 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.

Metadatensyntax für GitHub Actions

Du kannst Aktionen erstellen, um Aufgaben in deinem Repository auszuführen. Für Aktionen ist eine Metadatendatei erforderlich, die die YAML-Syntax verwendet.

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.

Informationen zur YAML-Syntax für GitHub Actions

Alle Aktionen erfordern eine Metadatendatei. Der Name der Metadatendatei muss entweder action.yml oder action.yaml lauten. Die Daten in der Metadaten-Datei definieren die Eingaben, Ausgaben und Laufzeitkonfiguration für die Aktion.

Metadaten-Dateien der Aktionen verwenden die YAML-Syntax. Lies YAML in fünf Minuten, wenn du noch keine Erfahrung mit YAML hast.

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. Eingabe-IDs in Großbuchstaben werden während der Laufzeit in Kleinbuchstaben umgewandelt. 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.

Hinweis: Workflows, die required: true verwenden, geben nicht automatisch einen Fehler zurück, wenn die Eingabe nicht für Ereignisse angegeben ist, die automatisch Workflowausführungen auslösen. Wenn du required: true in der Workflowdatei festlegst und workflow_dispatch verwendest, um den Workflow manuell auszuführen, musst du Eingaben auf GitHub.com angeben. Weitere Informationen findest du unter Ereignisse zum Auslösen von Workflows.

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.

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

Wenn du eine Eingabe in einer Workflowdatei angibst oder einen Standardeingabewert verwenden, 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 Aktion handelt, wird INPUT_<VARIABLE_NAME> nicht automatisch erstellt. Wenn die Konvertierung nicht stattfindet, kannst du diese Eingaben manuell ändern.

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).

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 veraltet 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 sind Unicode-Zeichenfolgen und können maximal 1 MB groß sein. Die Gesamtanzahl aller Ausgaben in einer Workflowausführung kann maximal 50 MB betragen.

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).

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

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), enthält jedoch das Token value.

Ausgaben sind Unicode-Zeichenfolgen und können maximal 1 MB groß sein. Die Gesamtanzahl aller Ausgaben in einer Workflowausführung kann maximal 50 MB betragen.

Beispiel: Deklarieren von Ausgaben für zusammengesetzte Aktionen

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 Kontexte.

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: Verwenden von Node.js v16

runs:
  using: 'node16'
  main: 'main.js'

runs.using für JavaScript-Aktionen

Erforderlich Die Runtime, mit der der in main angegebene Code ausgeführt wird.

  • Verwenden Sie node16 für Node.js v16.

runs.main

Erforderlich Die Datei, die deinen Aktionscode enthält. Die in using 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-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 außer Kraft setzen.

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

runs:
  using: 'node16'
  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.

  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-Syntax angegebene Runtime führt diese Datei aus.

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

runs:
  using: 'node16'
  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:

  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:

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

Alternativ kannst du auch $GITHUB_ACTION_PATH verwenden:

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

Weitere Informationen findest du unter Kontexte.

runs.steps[*].shell

Optional Die Shell, in der der Befehl ausgeführt werden soll. Du kannst eine der in „Workflowsyntax für GitHub Actions“ 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. Beispiel:

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

Weitere Informationen findest du unter Ausdrücke.

Beispiel: Verwenden von Kontexten

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

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 findest du unter Ausdrücke.

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 findest du unter Kontexte.

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 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 festlegen musst. Die erforderlichen Eingaben findest du in der README-Datei der Aktion.

runs:
  using: "composite"
  steps:
    # Reference a specific commit
    - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
    # Reference the major version of a release
    - uses: actions/checkout@v4
    # Reference a specific version
    - uses: actions/checkout@v4.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.

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

runs:
  using: 'docker'
  image: 'Dockerfile'

Beispiel: Verwenden des öffentlichen Docker-Registrierungscontainers

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 außer Kraft setzen.

Die mit der using-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:

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.

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 außer Kraft setzen.

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.

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

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

branding

Optional: Du kannst ein farbiges Feather-Symbol verwenden, um einen personalisierten Badge für deine Aktion zu erstellen. Badges werden neben dem Aktionsnamen in GitHub Marketplace angezeigt.

Beispiel: Konfigurieren des Brandings für eine Aktion

branding:
  icon: 'award'
  color: 'green'

branding.color

Die Hintergrundfarbe des Badges Optionen: white, yellow, blue, green, orange, red, purple oder gray-dark

branding.icon

Der Name des zu verwendenden Feather-Symbols (Version 4.28.0).

Ausgelassene Symbole

Markensymbole und alle folgenden Symbole werden weggelassen:

  • Kaffee
  • Spalten
  • divide-circle
  • divide-square
  • divide
  • frown
  • Hexagon
  • Schlüssel
  • meh
  • mouse-pointer
  • smile
  • Tool
  • x-octagon

Vollständige Liste aller derzeit unterstützten Symbole:

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