Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Veröffentlichen und Installieren eines Pakets mit GitHub Actions

Du kannst einen Workflow in GitHub Actions so konfigurieren, dass ein Paket aus GitHub Packages automatisch veröffentlicht oder installiert wird.

GitHub Packages ist verfügbar mit GitHub Free, GitHub Pro, GitHub Free für Organisationen, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server 3.0 oder höher, und GitHub AE. .
GitHub Packages ist nicht verfügbar für private Repositorys im Besitz von Konten mit älteren Pro-Repository-Plänen. Außerdem können Konten, die die alten Repository-Pläne verwenden, nicht auf die Container registry zugreifen, da diese Konten pro Repository abgerechnet werden. Weitere Informationen findest du unter GitHub-Produkte.

Informationen zu GitHub Packages with GitHub Actions

GitHub Actions helfen Dir, Deine Workflows für die Softwareentwicklung am gleichen Ort zu automatisieren, an dem Du Code speicherst und an Pull Requests und Issues mitarbeitest. Du kannst einzelne Aufgaben schreiben, Aktionen genannt, und diese kombinieren um einen benutzerdefinierten Workflow zu erstellen. Mit GitHub Actions können Sie End-to-End-Funktionen für die fortlaufende Integration und die fortlaufende Bereitstellung direkt im Repository erstellen. Weitere Informationen findest du unter Informationen zu GitHub Actions.

Du kannst die CI- und CD-Funktionen deines Repositorys erweitern, indem du Pakete als Teil deines Workflows veröffentlichst oder installierst.

Authentifizieren bei Paketregistrierungen mit differenzierten Berechtigungen

Einige GitHub Packages-Registrierungen unterstützen differenzierte Berechtigungen. Das bedeutet, dass du festlegen kannst, dass Pakete sich im Besitz eines Benutzers oder einer Organisation befinden oder mit einem Repository verknüpft sein dürfen. Die Liste mit Registrierungen, die differenzierte Berechtigungen unterstützen, findest du unter Informationen zu Berechtigungen für GitHub Packages.

Wenn dein GitHub Actions-Workflow ein personal access token zum Authentifizieren bei einer Registrierung verwendet, solltest du für Registrierungen, die differenzierte Berechtigungen unterstützen, deinen Workflow unbedingt so aktualisieren, dass das GITHUB_TOKEN verwendet wird. Anleitungen zum Aktualisieren deiner Workflows, die sich mit einem personal access token bei einer Registrierung authentifizieren, findest du unter Upgrade eines Workflows mit Registrierungszugriff über ein personal access token.

Hinweis: Die Möglichkeit für GitHub Actions-Workflows, Pakete mithilfe der REST-API zu löschen und wiederherzustellen, befindet sich derzeit in der öffentlichen Betaphase und kann sich ändern.

Du kannst ein GITHUB_TOKEN in einem GitHub Actions-Workflow verwenden, um Pakete mithilfe der REST-API zu löschen oder wiederherzustellen, wenn das Token über die admin-Berechtigung für das Paket verfügt. Repositorys, die Pakete mithilfe eines Workflows veröffentlichen, und Repositorys, die du explizit mit Paketen verbunden hast, erhalten automatisch die admin-Berechtigung für Pakete im Repository.

Weitere Informationen über das GITHUB_TOKEN findest du unter Authentifizierung in einem Workflow. Weitere Informationen zu den Best Practices bei der Verwendung einer Registrierung in Actions findest du unter Sicherheitshärtung für GitHub Actions.

Authentifizieren bei Paketregistrierungen mit repositorybezogenen Berechtigungen

Einige GitHub Packages-Registrierungen unterstützen nur repositorybezogene Berechtigungen und keine differenzierten Berechtigungen. Eine Liste dieser Registrierungen findest du unter Informationen zu Berechtigungen für GitHub Packages.

Wenn dein Workflow Zugriff auf eine GitHub Packages-Registrierung benötigt, die keine differenzierten Berechtigungen unterstützt, empfehlen wir die Verwendung des GitHub-Tokens (GITHUB_TOKEN), das GitHub automatisch für dein Repository erstellt, wenn du GitHub Actions aktivierst. Die Berechtigungen für dieses Zugriffstoken müssen in der Workflowdatei festgelegt werden, um den Lesezugriff auf den contents-Bereich und Schreibzugriff auf den packages-Bereich zu gewähren. Für Forks erhält GITHUB_TOKEN den Lesezugriff für das übergeordnete Repository. Weitere Informationen findest du unter Authenticating with the GITHUB_TOKEN („Authentifizieren mit dem GITHUB_TOKEN“).

Du kannst auf das GITHUB_TOKEN in deiner Workflowdatei mithilfe des {{secrets.GITHUB_TOKEN}}-Kontexts verweisen. Weitere Informationen findest du unter Authenticating with the GITHUB_TOKEN („Authentifizieren mit dem GITHUB_TOKEN“).

Informationen zu Berechtigungen und zum Paketzugriff

Auf Benutzer oder Organisationen ausgerichtete Pakete

Registrierungen, die differenzierte Berechtigungen unterstützen, ermöglichen es Benutzern, Pakete als eigenständige Ressourcen auf Organisationsebene zu erstellen und zu verwalten. Pakete können im Besitz einer Organisation oder eines persönlichen Kontos sein, und du kannst den Zugriff auf jedes deiner Pakete separat über die Repositoryberechtigungen anpassen.

Alle Workflows, die auf Registrierungen zugreifen, die differenzierte Berechtigungen unterstützen, sollten kein personal access token verwenden, sondern das GitHub-Token (GITHUB_TOKEN). Weitere Informationen zu bewährten Sicherheitsmethoden findest du unter Sicherheitshärtung für GitHub Actions.

Auf Repositorys ausgerichtete Pakete

Wenn du GitHub Actions aktivierst, installiert GitHub eine GitHub App im Repository. Das GITHUB_TOKEN-Geheimnis ist ein Zugriffstoken der GitHub-App-Installation. Du kannst das Installationszugriffstoken verwenden, um dich im Namen der auf deinem Repository installierten GitHub-App zu authentifizieren. Die Berechtigungen des Tokens sind auf das Repository beschränkt, in dem sich der Workflow befindet. Weitere Informationen findest du unter Berechtigungen für das GITHUB_TOKEN.

GitHub Packages ermöglicht es dir, Pakete über das GITHUB_TOKEN zu pushen und pullen, das für einen GitHub Actions-Workflow verfügbar ist.

Standardberechtigungen und Zugriffseinstellungen für Container, die über Workflows geändert wurden

Wenn du einen Container über einen Workflow erstellst, installierst, änderst oder löschst, gibt es einige Standardberechtigungen und Zugriffseinstellungen, die verwendet werden, um sicherzustellen, dass Administrator*innen Zugriff auf den Workflow haben. Du kannst diese Zugriffseinstellungen auch anpassen.

Standardmäßig geschieht Folgendes, wenn ein Workflow mithilfe von GITHUB_TOKEN einen Container erstellt:

  • Der Container erbt das Sichtbarkeits- und Berechtigungsmodell des Repositorys, in dem der Workflow ausgeführt wird.
  • Repositoryadministratorinnen, für die der Workflow ausgeführt wird, werden die Administratorinnen des Containers, sobald der Container erstellt wurde.

Dies sind weitere Beispiele für die Funktionsweise von Standardberechtigungen für Workflows, die Pakete verwalten.

GitHub Actions-WorkflowaufgabeStandardberechtigungen und -zugriff
Herunterladen eines bestehenden Containers– Wenn der Container öffentlich ist, kann jeder Workflow, der in einem beliebigen Repository ausgeführt wird, den Container herunterladen.
– Wenn der Container intern ist, können alle Workflows, die in einem Repository ausgeführt werden, das im Besitz des Enterprise-Kontos ist, den Container herunterladen. Für unternehmenseigene Organisationen kannst du jedes Repository im Unternehmen lesen.
– Wenn der Container privat ist, können nur Workflows, die in Repositorys ausgeführt werden, die Leseberechtigung für diesen Container erhalten, den Container herunterladen.
Hochladen einer neuen Version zu einem vorhandenen Container– Wenn der Container privat, intern oder öffentlich ist, können nur Workflows, die in Repositorys ausgeführt werden, die Schreibberechtigungen für diesen Container erhalten, neue Versionen in den Container hochladen.
Löschen eines Containers oder einer Version eines Containers– Wenn der Container privat, intern oder öffentlich ist, können nur Workflows, die in Repositorys mit Administratorberechtigungen ausgeführt werden, vorhandene Versionen des Containers löschen.

Du kannst auch den Zugriff auf Container präziser anpassen oder das Verhalten von Standardberechtigungen anpassen. Weitere Informationen findest du unter Konfigurieren der Zugriffssteuerung und Sichtbarkeit eines Pakets.

Veröffentlichen eines Pakets mithilfe einer Aktion

Du kannst GitHub Actions verwenden, um automatisch Pakete als Teil deines CI-Flows (Continuous Integration) zu veröffentlichen. Mit diesem Ansatz für Continuous Deployment (CD) kannst du die Erstellung neuer Paketversionen automatisieren, wenn der Code deinen Qualitätsstandards entspricht. Beispielsweise kannst du einen Workflow erstellen, der CI-Tests jedes Mal ausführt, wenn eine Entwicklerin Code an einen bestimmten Branch pusht. Wenn die Tests bestanden werden, kann der Workflow eine neue Paketversion in GitHub Packages veröffentlichen.

Die Konfigurationsschritte variieren je nach Paketclient. Allgemeine Informationen zum Konfigurieren eines Workflows für GitHub Actions findest du unter Konfigurieren eines Workflows.

Im folgenden Beispiel wird veranschaulicht, wie du GitHub Actions verwenden kannst, um zu erstellen und zu testen und anschließend automatisch ein Docker-Image zu erstellen und es in GitHub Packages zu veröffentlichen.

Erstelle eine neue Workflowdatei in deinem Repository (z. B. .github/workflows/deploy-image.yml), und füge die folgende YAML-Datei hinzu:

YAML
# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.

# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.
# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.
# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.

name: Create and publish a Docker image

on:
 push:
   branches: ['release']

env:
 REGISTRY: ghcr.io
 IMAGE_NAME: ${{ github.repository }}

jobs:
 build-and-push-image:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     packages: write

   steps:
     - name: Checkout repository
       uses: actions/checkout@v3

     - name: Log in to the Container registry
       uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
       with:
         registry: ${{ env.REGISTRY }}
         username: ${{ github.actor }}
         password: ${{ secrets.GITHUB_TOKEN }}

     - name: Extract metadata (tags, labels) for Docker
       id: meta
       uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
       with:
         images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

     - name: Build and push Docker image
       uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
       with:
         context: .
         push: true
         tags: ${{ steps.meta.outputs.tags }}
         labels: ${{ steps.meta.outputs.labels }}

Die relevanten Einstellungen werden in der folgenden Tabelle erläutert. Ausführliche Informationen zu jedem Element in einem Workflow findest du unter Workflowsyntax für GitHub Actions.

```yaml on: push: branches: ['release'] ``` Hier wird der Create and publish a Docker image-Workflow konfiguriert, der jedes mal ausgeführt wird, wenn eine Änderung an den Branch release gepusht wird.
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
Definiert zwei benutzerdefinierte Umgebungsvariablen für den Workflow. Diese werden für die Container registry-Domäne und einen Namen für das Docker-Image verwendet, das dieser Workflow erstellt.
jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
In diesem Workflow gibt es einen einzelnen Auftrag. Er ist so konfiguriert, dass er auf der neuesten verfügbaren Version von Ubuntu ausgeführt wird.
```yaml permissions: contents: read packages: write ``` Legt die Berechtigungen fest, die für das GITHUB_TOKEN für die Aktionen in diesem Auftrag gewährt werden
```yaml - name: Log in to the Container registry uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} ``` Erstellt einen Schritt namens Log in to the Container registry, der sich mit dem Konto und dem Kennwort anmeldet, das die Pakete veröffentlicht. Nach der Veröffentlichung befinden sich die Pakete im Besitz des hier definierten Kontos.
```yaml - name: Extract metadata (tags, labels) for Docker id: meta uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} ``` In diesem Schritt wird docker/metadata-action verwendet, um Tags und Bezeichnungen zu extrahieren, die auf das angegebene Image angewendet werden. Mit der id „meta“ kann auf die Ausgabe dieses Schritts in einem nachfolgenden Schritt verwiesen werden. Der images-Wert stellt den Basisnamen für die Tags und Bezeichnungen bereit.
```yaml - name: Build and push Docker image ``` Erstellt einen neuen Schritt namens Build and push Docker image. Dieser Schritt wird als Teil des build-and-push-image-Auftrags ausgeführt.
```yaml uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc ``` Verwendet die Docker-Aktion build-push-action, um das Image basierend auf dem Dockerfile deines Repositorys zu erstellen. Wenn der Build erfolgreich ist, wird das Image an GitHub Packages gepusht.
```yaml with: ``` Sendet die erforderlichen Parameter an die build-push-action-Aktion. Diese werden in den nachfolgenden Zeilen definiert.
```yaml context: . ``` Hiermit wird der Kontext des Builds als Gruppe von Dateien im angegebenen Pfad definiert. Weitere Informationen findest du unter Verbrauch.
```yaml push: true ``` Hier wird das Image an die Registrierung gepusht, wenn es erfolgreich erstellt wurde.
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
Hier werden die Tags und Bezeichnungen hinzugefügt, die im „meta“-Schritt extrahiert wurden.

Dieser neue Workflow wird jedes Mal automatisch ausgeführt, wenn du eine Änderung an einem Branch mit dem Namen release im Repository pushst. Auf der Registerkarte Aktionen kannst du den Fortschritt nachverfolgen.

Ein paar Minuten nach Abschluss des Workflows wird das neue Paket in deinem Repository angezeigt. Informationen zum Suchen deiner verfügbaren Pakete findest du unter Anzeigen der Pakete eines Repositorys.

Installieren eines Pakets mithilfe einer Aktion

Du kannst Pakete als Teil deines CI-Flows mithilfe von GitHub Actions erstellen. Beispielsweise kannst du einen Workflow konfigurieren. Jedes Mal, wenn eine Entwicklerin Code an einen Pull Request pusht, löst der Workflow die Abhängigkeiten auf, indem er Pakete herunterlädt und installiert, die von GitHub Packages gehostet werden. Anschließend kann der Workflow CI-Tests ausführen, die die Abhängigkeiten erfordern.

Die Installation von Paketen, die von GitHub Packages über GitHub Actions gehostet werden, erfordert eine minimale Konfiguration oder zusätzliche Authentifizierung, wenn du GITHUB_TOKEN verwendest. Datenübertragungen sind auch kostenlos, wenn eine Aktion ein Paket installiert. Weitere Informationen findest du unter Informationen zur Abrechnung für GitHub Packages.

Die Konfigurationsschritte variieren je nach Paketclient. Allgemeine Informationen zum Konfigurieren eines Workflows für GitHub Actions findest du unter Konfigurieren eines Workflows.

Upgraden eines Workflows, der ein personal access token für den Zugriff auf eine Registrierung verwendet

GitHub Packages unterstützt das GitHub-Token (GITHUB_TOKEN) für eine einfache und sichere Authentifizierung in deinen Workflows. Wenn du eine Registrierung verwendest, die differenzierte Berechtigungen unterstützt, und dein Workflow ein personal access token zum Authentifizieren bei einer Registrierung verwendet, solltest du deinen Workflow unbedingt aktualisieren, um das GitHub-Token (GITHUB_TOKEN) zu verwenden.

Weitere Informationen über das GITHUB_TOKEN findest du unter Authentifizierung in einem Workflow.

Wenn du das GitHub-Token (GITHUB_TOKEN) verwendest anstatt ein personal access token (classic) mit dem Bereich repo, erhöht sich die Sicherheit deines Repositorys, da du kein langlebiges personal access token verwenden musst, das unnötigen Zugriff auf das Repository bietet, in dem dein Workflow ausgeführt wird. Weitere Informationen zu bewährten Sicherheitsmethoden findest du unter Sicherheitshärtung für GitHub Actions.

  1. Navigiere zur Landing Page deines Pakets.

  2. Klicke auf der linken Randleiste auf Actions-Zugriff. Die Option „Actions-Zugriff“ im Menü auf der linken Seite

  3. Um sicherzustellen, dass dein Containerpaket Zugriff auf deinen Workflow hat, musst du das Repository hinzufügen, in dem der Workflow für deinen Container gespeichert ist. Klicke auf Repository hinzufügen, und suche nach dem Repository, das hinzugefügt werden soll. Schaltfläche „Repository hinzufügen“

    Hinweis: Der Vorgang zum Hinzufügen eines Repositorys zu deinem Container über das Menü für den Actions-Zugriff unterscheidet sich vom Vorgang, bei dem dein Container mit einem Repository verbunden wird. Weitere Informationen findest du unter Sicherstellen des Workflowzugriffs auf dein Paket und Verbinden eines Repositorys mit einem Paket.

  4. Wähle optional über das Dropdownmenü „Rolle“ die Standardzugriffsebene aus, die du dem Repository für deinem Containerimage zuweisen möchten. Berechtigungszugriffsebenen für Repositorys

  5. Öffne deine Workflowdatei. Ersetze in der Zeile, über die du dich bei der Registrierung anmeldest, dein personal access token durch ${{ secrets.GITHUB_TOKEN }}.

Dieser Workflow veröffentlicht beispielsweise ein Docker-Image in der Container registry und verwendet ${{ secrets.GITHUB_TOKEN }} für die Authentifizierung.

YAML
name: Demo Push

on:
  push:
    # Publish `master` as Docker `latest` image.
    branches:
      - master
      - seed

    # Publish `v1.2.3` tags as releases.
    tags:
      - v*

  # Run tests for any PRs.
  pull_request:

env:
  IMAGE_NAME: ghtoken_product_demo

jobs:
  # Push image to GitHub Packages.
  # See also https://docs.docker.com/docker-hub/builds/
  push:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

    steps:
      - uses: actions/checkout@v3

      - name: Build image
        run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"

      - name: Log in to registry
        # This is where you will update the personal access token to GITHUB_TOKEN
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u $ --password-stdin

      - name: Push image
        run: |
          IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME

          # Change all uppercase to lowercase
          IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
          # Strip git ref prefix from version
          VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
          # Strip "v" prefix from tag name
          [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
          # Use Docker `latest` tag convention
          [ "$VERSION" == "master" ] && VERSION=latest
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=$VERSION
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION