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 auf Benutzer*innen oder eine Organisation ausgerichtet werden oder mit einem Repository verknüpft sein dürfen. Eine Liste dieser Registrierungen, die differenzierte Berechtigungen unterstützen, findest du unter Informationen zu Berechtigungen für GitHub-Pakete.
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. Eine Anleitung zum Aktualisieren deiner Workflows, die sich mit einem personal access token bei einer Registrierung authentifizieren, findest du unter Veröffentlichen und Installieren eines Pakets mit GitHub Actions.
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.
Sie können ein GITHUB_TOKEN
in einem GitHub Actions-Workflow verwenden, um ein Paket 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 zum GITHUB_TOKEN
findest du unter Automatische Tokenauthentifizierung. 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-Pakete.
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 Enterprise Server 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 Automatische Tokenauthentifizierung.
Du kannst auf das GITHUB_TOKEN
in deiner Workflowdatei mithilfe des ${{ secrets.GITHUB_TOKEN }}
-Kontexts verweisen. Weitere Informationen findest du unter Automatische Tokenauthentifizierung.
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 einer Organisation oder einem persönlichen Kontos zugeordnet werden, 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 Methoden für die Sicherheit 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 Automatische Tokenauthentifizierung.
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 Pakete, die über Workflows geändert wurden
Wenn du für Pakete in Registrierungen, die differenzierte Berechtigungen unterstützen, ein Paket ü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. Eine Liste dieser Registrierungen, die differenzierte Berechtigungen unterstützen, findest du unter Informationen zu Berechtigungen für GitHub-Pakete.
Standardmäßig geschieht Folgendes, wenn ein Workflow mithilfe von GITHUB_TOKEN
ein Paket erstellt:
- Das Paket 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 Pakets, sobald dieses erstellt wurde.
Dies sind weitere Beispiele für die Funktionsweise von Standardberechtigungen für Workflows, die Pakete verwalten.
GitHub Actions-Workflowaufgabe | Standardberechtigungen und -zugriff |
---|---|
Dient zum Herunterladen eines vorhandenen Pakets | – Wenn das Paket öffentlich ist, kann jeder Workflow, der in einem beliebigen Repository ausgeführt wird, dieses herunterladen. – Wenn das Paket intern ist, können alle Workflows, die in einem Repository ausgeführt werden, das im Besitz des Enterprise-Kontos ist, das Paket herunterladen. Für unternehmenseigene Organisationen kannst du jedes Repository im Unternehmen lesen. – Wenn das Paket privat ist, können nur Workflows, die in Repositorys ausgeführt werden, die Leseberechtigung für dieses Paket erhalten, dieses herunterladen. Wenn du einem öffentlichen Repository Zugriff auf private Pakete gewährst, können Forks des Repositorys auf die privaten Pakete zugreifen. |
Hochladen einer neuen Version zu einem vorhandenen Paket | – Wenn das Paket privat, intern oder öffentlich ist, können nur Workflows, die in Repositorys ausgeführt werden, die Schreibberechtigungen für dieses Paket erhalten, neue Versionen in das Paket hochladen. |
Löschen eines Pakets oder von Versionen eines Pakets | – Wenn das Paket privat, intern oder öffentlich ist, können nur Workflows, die in Repositorys mit Administratorberechtigungen ausgeführt werden, vorhandene Versionen des Pakets löschen. |
Du kannst auch den Zugriff auf Pakete präziser anpassen oder das Verhalten von Standardberechtigungen anpassen. Weitere Informationen findest du unter Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen.
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 Verwenden von Workflows.
Im folgenden Beispiel wird veranschaulicht, wie du GitHub Actions verwenden kannst, um deine App zu erstellen und zu testen und anschließend automatisch ein Docker-Image zu erstellen und es in GitHub Packages zu veröffentlichen. Die relevanten Einstellungen werden im Code erläutert. Weitere Informationen zu den einzelnen Elementen in einem Workflow findest du unter Workflowsyntax für GitHub Actions.
Erstelle eine neuen Workflowdatei in deinem Repository (z. B. .github/workflows/deploy-image.yml
), und füge die folgende YAML-Datei hinzu.
Hinweise:
- Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert wurden. Sie werden von einem Drittanbieter bereitgestellt und unterliegen separaten Nutzungsbedingungen, Datenschutzrichtlinien und Supportdokumentationen.
- Wenn du einen SHA auswählen, solltest du überprüfen, ob er aus dem Repository der Aktion und nicht aus einem Repositoryfork stammt.
# name: Create and publish a Docker image # Configures this workflow to run every time a change is pushed to the branch called `release`. on: push: branches: ['release'] jobs: # This job checks out the repository contents, installs `npm`, uses npm and webpack to build the app, and uploads the built files as an artifact that can be downloaded later in the workflow. # It assumes that the built files are written to a directory called `public`. run-npm-build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: npm install and build webpack run: | npm install npm run build - uses: actions/upload-artifact@v3 with: name: webpack artifacts path: public/ # This job uses `npm test` to test the code. `needs: run-npm-build` makes this job dependent on the `run-npm-build` job. run-npm-test: runs-on: ubuntu-latest needs: run-npm-build strategy: matrix: os: [ubuntu-latest] node-version: [14.x, 16.x] steps: - uses: actions/checkout@v4 - name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} - uses: actions/download-artifact@v3 with: name: webpack artifacts path: public - name: npm install, and test run: | npm install npm test env: CI: true # This job publishes the package. `needs: run-npm-test` makes this job dependent on the `run-npm-test` job. build-and-push-image: runs-on: ubuntu-latest needs: run-npm-test # Sets the permissions granted to the `GITHUB_TOKEN` for the actions in this job. permissions: contents: read packages: write # steps: - name: Checkout uses: actions/checkout@v4 # Uses the `docker/login-action` action to log in to the registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here. - name: Log in to GitHub Docker Registry uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1 with: registry: docker.pkg.github.com username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} # This step uses the `docker/build-push-action` action to build the image, based on your repository's `Dockerfile`. If the build succeeds, it pushes the image to GitHub Packages. # It uses the `tags` parameter to tag the image with the SHA of the commit that triggered the workflow. - name: Build and push Docker image uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4 with: push: true tags: | docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }}
name: Create and publish a Docker image
on:
push:
branches: ['release']
jobs:
Configures this workflow to run every time a change is pushed to the branch called release
.
run-npm-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@v3
with:
name: webpack artifacts
path: public/
This job checks out the repository contents, installs npm
, uses npm and webpack to build the app, and uploads the built files as an artifact that can be downloaded later in the workflow.
It assumes that the built files are written to a directory called public
.
run-npm-test:
runs-on: ubuntu-latest
needs: run-npm-build
strategy:
matrix:
os: [ubuntu-latest]
node-version: [14.x, 16.x]
steps:
- uses: actions/checkout@v4
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- uses: actions/download-artifact@v3
with:
name: webpack artifacts
path: public
- name: npm install, and test
run: |
npm install
npm test
env:
CI: true
This job uses npm test
to test the code. needs: run-npm-build
makes this job dependent on the run-npm-build
job.
build-and-push-image:
runs-on: ubuntu-latest
needs: run-npm-test
This job publishes the package. needs: run-npm-test
makes this job dependent on the run-npm-test
job.
permissions:
contents: read
packages: write
Sets the permissions granted to the GITHUB_TOKEN
for the actions in this job.
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Log in to GitHub Docker Registry
uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
with:
registry: docker.pkg.github.com
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
Uses the docker/login-action
action to log in to the registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.
- name: Build and push Docker image
uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
with:
push: true
tags: |
docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }}
This step uses the docker/build-push-action
action to build the image, based on your repository's Dockerfile
. If the build succeeds, it pushes the image to GitHub Packages.
It uses the tags
parameter to tag the image with the SHA of the commit that triggered the workflow.
#
name: Create and publish a Docker image
# Configures this workflow to run every time a change is pushed to the branch called `release`.
on:
push:
branches: ['release']
jobs:
# This job checks out the repository contents, installs `npm`, uses npm and webpack to build the app, and uploads the built files as an artifact that can be downloaded later in the workflow.
# It assumes that the built files are written to a directory called `public`.
run-npm-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@v3
with:
name: webpack artifacts
path: public/
# This job uses `npm test` to test the code. `needs: run-npm-build` makes this job dependent on the `run-npm-build` job.
run-npm-test:
runs-on: ubuntu-latest
needs: run-npm-build
strategy:
matrix:
os: [ubuntu-latest]
node-version: [14.x, 16.x]
steps:
- uses: actions/checkout@v4
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- uses: actions/download-artifact@v3
with:
name: webpack artifacts
path: public
- name: npm install, and test
run: |
npm install
npm test
env:
CI: true
# This job publishes the package. `needs: run-npm-test` makes this job dependent on the `run-npm-test` job.
build-and-push-image:
runs-on: ubuntu-latest
needs: run-npm-test
# Sets the permissions granted to the `GITHUB_TOKEN` for the actions in this job.
permissions:
contents: read
packages: write
#
steps:
- name: Checkout
uses: actions/checkout@v4
# Uses the `docker/login-action` action to log in to the registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.
- name: Log in to GitHub Docker Registry
uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
with:
registry: docker.pkg.github.com
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
# This step uses the `docker/build-push-action` action to build the image, based on your repository's `Dockerfile`. If the build succeeds, it pushes the image to GitHub Packages.
# It uses the `tags` parameter to tag the image with the SHA of the commit that triggered the workflow.
- name: Build and push Docker image
uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
with:
push: true
tags: |
docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }}
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 Ihrem Repository angezeigt. Weitere Informationen zum Suchen deiner verfügbaren Pakete findest du unter Pakete anzeigen.
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.
Die Konfigurationsschritte variieren je nach Paketclient. Allgemeine Informationen zum Konfigurieren eines Workflows für GitHub Actions findest du unter Verwenden von 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 zum GITHUB_TOKEN
findest du unter Automatische Tokenauthentifizierung.
Wenn du das GitHub-Token (GITHUB_TOKEN
) verwendest anstatt ein personal access token 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 Methoden für die Sicherheit findest du unter Sicherheitshärtung für GitHub Actions.
- Navigiere zur Landing Page deines Pakets.
- Klicke auf der linken Randleiste auf Actions-Zugriff.
- Um sicherzustellen, dass dein Paket Zugriff auf deinen Workflow hat, musst du das Repository hinzufügen, in dem der Workflow für dein Paket gespeichert ist. Wähle Repository hinzufügen aus, und suche nach dem Repository, das du hinzufügen möchtest.
Hinweis: Das Hinzufügen eines Repositorys zu deinem Paket über das über die Menüoption in Actions-Zugriff unterscheidet sich von dem Vorgang, bei dem dein Container mit einem Repository verknüpft wird. Weitere Informationen findest du unter Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen und unter Verbinden eines Repositorys mit einem Paket.
Dieser Workflow veröffentlicht beispielsweise ein Docker-Image in der Container registry und verwendet ${{ secrets.GITHUB_TOKEN }}
für die Authentifizierung. Weitere Informationen findest du unter Einrichten automatisierter Builds in der Docker-Dokumentation.
# name: Demo Push # This workflow runs when any of the following occur: # - A push is made to a branch called `main` or `seed` # - A tag starting with "v" is created # - A pull request is created or updated on: push: branches: - main - seed tags: - v* pull_request: # This creates an environment variable called `IMAGE_NAME ` with the value `ghtoken_product_demo`. env: IMAGE_NAME: ghtoken_product_demo # jobs: # This pushes the image to GitHub Packages. push: runs-on: ubuntu-latest permissions: packages: write contents: read # steps: - uses: actions/checkout@v4 - name: Build image run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}" - name: Log in to registry run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin # - name: Push image run: | IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME # This changes all uppercase characters to lowercase. IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]') # This strips the git ref prefix from the version. VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,') # This strips the "v" prefix from the tag name. [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//') # This uses the Docker `latest` tag convention. [ "$VERSION" == "main" ] && VERSION=latest echo IMAGE_ID=$IMAGE_ID echo VERSION=$VERSION docker tag $IMAGE_NAME $IMAGE_ID:$VERSION docker push $IMAGE_ID:$VERSION
name: Demo Push
on:
push:
branches:
- main
- seed
tags:
- v*
pull_request:
This workflow runs when any of the following occur:
- A push is made to a branch called
main
orseed
- A tag starting with "v" is created
- A pull request is created or updated
env:
IMAGE_NAME: ghtoken_product_demo
This creates an environment variable called IMAGE_NAME
with the value ghtoken_product_demo
.
jobs:
push:
runs-on: ubuntu-latest
permissions:
packages: write
contents: read
This pushes the image to GitHub Packages.
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"
- name: Log in to registry
run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
- name: Push image
run: |
IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME
IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
This changes all uppercase characters to lowercase.
VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
This strips the git ref prefix from the version.
[[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
This strips the "v" prefix from the tag name.
[ "$VERSION" == "main" ] && VERSION=latest
echo IMAGE_ID=$IMAGE_ID
echo VERSION=$VERSION
docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
docker push $IMAGE_ID:$VERSION
This uses the Docker latest
tag convention.
#
name: Demo Push
# This workflow runs when any of the following occur:
# - A push is made to a branch called `main` or `seed`
# - A tag starting with "v" is created
# - A pull request is created or updated
on:
push:
branches:
- main
- seed
tags:
- v*
pull_request:
# This creates an environment variable called `IMAGE_NAME ` with the value `ghtoken_product_demo`.
env:
IMAGE_NAME: ghtoken_product_demo
#
jobs:
# This pushes the image to GitHub Packages.
push:
runs-on: ubuntu-latest
permissions:
packages: write
contents: read
#
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"
- name: Log in to registry
run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
#
- name: Push image
run: |
IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME
# This changes all uppercase characters to lowercase.
IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
# This strips the git ref prefix from the version.
VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
# This strips the "v" prefix from the tag name.
[[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
# This uses the Docker `latest` tag convention.
[ "$VERSION" == "main" ] && VERSION=latest
echo IMAGE_ID=$IMAGE_ID
echo VERSION=$VERSION
docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
docker push $IMAGE_ID:$VERSION