Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Publication et installation d’un package avec GitHub Actions

Vous pouvez configurer un workflow dans GitHub Actions pour publier ou installer automatiquement un package à partir de GitHub Packages.

GitHub Packages est disponible avec GitHub Free, GitHub Pro, GitHub Free pour les organisations, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server 3.0 ou version ultérieure et GitHub AE.
GitHub Packages n’est pas disponible pour les référentiels privés appartenant à des comptes qui utilisent des plans par référentiel hérités. En outre, les comptes qui utilisent des plans par référentiel hérités n’ont pas accès au Container registry puisque ces comptes sont facturés par référentiel. Pour plus d’informations, consultez « Produits de GitHub ».

À propos de GitHub Packages avec GitHub Actions

GitHub Actions vous aide à automatiser vos workflows de développement logiciel au même endroit où vous stockez le code et collaborez sur les demandes de tirage et les problèmes. Vous pouvez écrire des tâches individuelles, appelées actions, et les combiner pour créer un workflow personnalisé. Avec GitHub Actions, vous pouvez créer des fonctionnalités d’intégration continue (CI) et de déploiement continu (CD) de bout en bout directement dans votre dépôt. Pour plus d’informations, consultez « À propos de GitHub Actions ».

Vous pouvez étendre les fonctionnalités CI et CD de votre dépôt en publiant ou en installant des packages dans le cadre de votre workflow.

Authentification auprès des registres de packages avec des autorisations granulaires

Certains registres GitHub Packages prennent en charge les autorisations granulaires. Cela signifie que vous pouvez choisir de permettre aux packages d’appartenir à un utilisateur ou une organisation, ou d’être lié à un dépôt. Pour obtenir la liste des registres qui prennent en charge les autorisations granulaires, consultez « À propos des autorisations pour GitHub Packages ».

Pour les registres prenant en charge les autorisations granulaires, si votre workflow GitHub Actions utilise un personal access token pour s’authentifier auprès d’un registre, nous vous recommandons vivement de mettre à jour votre workflow pour utiliser GITHUB_TOKEN. Pour obtenir des conseils sur la mise à jour de vos workflows qui s’authentifient auprès d’un registre avec un personal access token, consultez « Mise à niveau d’un workflow qui accède à un registre à l’aide d’un personal access token ».

Remarque : la capacité des workflows GitHub Actions de supprimer et de restaurer des packages à l’aide de l’API REST est actuellement en version bêta publique et susceptible d’être modifiée.

Vous pouvez utiliser un GITHUB_TOKEN dans un workflow GitHub Actions pour supprimer ou restaurer un package via l’API REST si le jeton dispose de l’autorisation admin sur le package. Les référentiels qui publient des packages à l’aide d’un workflow et les référentiels que vous avez explicitement connectés à des packages se voient automatiquement accorder l’autorisation admin aux packages dans le référentiel.

Pour plus d’informations sur le secret GITHUB_TOKEN, consultez « Authentification dans un workflow ». Pour plus d’informations sur les meilleures pratiques d’utilisation d’un registre dans des actions, consultez « Durcissement de la sécurité pour GitHub Actions ».

Authentification auprès des registres de packages avec des autorisations limitées au dépôt

Certains registres GitHub Packages prennent uniquement en charge les autorisations limitées au dépôt, ils ne prennent pas en charge les autorisations granulaires. Pour obtenir la liste de ces registres, consultez « À propos des autorisations pour GitHub Packages ».

Si vous voulez que votre workflow accède à un registre GitHub Packages qui ne prend pas en charge les autorisations granulaires, nous recommandons d’utiliser GITHUB_TOKEN que GitHub crée automatiquement pour votre dépôt quand vous activez GitHub Actions. Vous devez définir les autorisations de ce jeton d’accès dans le fichier de workflow afin d’octroyer l’accès en lecture pour l’étendue contents et l’accès en écriture pour l’étendue packages. Pour les duplications, GITHUB_TOKEN reçoit un accès en lecture pour le dépôt parent. Pour plus d’informations, consultez « Authentification avec GITHUB_TOKEN ».

Vous pouvez référencer le GITHUB_TOKEN de votre fichier de workflow à l’aide du contexte {{secrets.GITHUB_TOKEN}}. Pour plus d’informations, consultez « Authentification avec GITHUB_TOKEN ».

À propos des autorisations et de l’accès aux packages

Packages limités aux utilisateurs ou aux organisations

Les registres qui prennent en charge les autorisations granulaires autorisent les utilisateurs à créer et à administrer des packages en tant que ressources autonomes au niveau de l’organisation. Les packages peuvent appartenir à un compte d’organisation ou personnel, et vous pouvez personnaliser l’accès à chacun de vos packages séparément des autorisations de dépôt.

Tous les workflows accédant aux registres qui prennent en charge les autorisations granulaires doivent utiliser GITHUB_TOKEN au lieu d’un personal access token. Pour plus d’informations sur les meilleures pratiques en matière de sécurité, consultez « Renforcement de la sécurité pour GitHub Actions ».

Packages limités aux dépôts

Lorsque vous activez GitHub Actions, GitHub installe une application GitHub sur votre dépôt. Le secret GITHUB_TOKEN est un jeton d’accès d’installation d’application GitHub. Vous pouvez utiliser le jeton d’accès d’installation pour vous authentifier au nom de l’application GitHub installée sur votre dépôt. Les autorisations du jeton sont limitées au dépôt qui contient votre workflow. Pour plus d’informations, consultez « Autorisations pour le secret GITHUB_TOKEN ».

GitHub Packages vous permet d’envoyer (push) et d’extraire des packages via le secret GITHUB_TOKEN disponible pour un workflow GitHub Actions.

Autorisations et paramètres d’accès par défaut pour les conteneurs, modifiés via des workflows

Lorsque vous créez, installez, modifiez ou supprimez un conteneur via un workflow, certains paramètres d’accès et autorisations par défaut sont utilisés pour garantir l’accès des administrateurs au workflow. Vous pouvez également ajuster ces paramètres d’accès.

Par exemple, par défaut, si un workflow crée un conteneur à l’aide du secret GITHUB_TOKEN :

  • Le conteneur hérite du modèle de visibilité et d’autorisations du dépôt où le workflow est exécuté.
  • Les administrateurs du dépôt où le flux de travail est exécuté deviennent administrateurs du conteneur une fois celui-ci créé.

Voici d’autres exemples montrant comment les autorisations par défaut fonctionnent pour des workflows qui gèrent des packages.

Tâche de workflow GitHub ActionsAutorisations et accès par défaut
Télécharger un conteneur existant- Si le conteneur est public, tout workflow s’exécutant dans n’importe quel dépôt peut télécharger le conteneur.
- Si le conteneur est interne, tout workflow s’exécutant dans n’importe quel dépôt appartenant au compte d’entreprise peut télécharger le conteneur. Pour les organisations appartenant à une entreprise, vous pouvez lire n’importe quel dépôt dans l’entreprise
- Si le conteneur est privé, seuls les workflows s’exécutant dans des dépôts qui reçoivent une autorisation de lecture sur ce conteneur peuvent télécharger celui-ci.
Charger une nouvelle version dans un conteneur existant- Si le conteneur est privé, interne ou public, seuls les workflows s’exécutant dans des dépôts qui reçoivent l’autorisation d’écriture sur ce conteneur peuvent charger de nouvelles versions dans le conteneur.
Supprimer un conteneur ou des versions d’un conteneur- Si le conteneur est privé, interne ou public, seuls les workflows s’exécutant dans des dépôts qui reçoivent l’autorisation admin peuvent supprimer des versions existantes du conteneur.

Vous pouvez également ajuster l’accès aux conteneurs d’une manière plus précise, ou ajuster en partie le comportement des autorisations par défaut. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».

Publication d’un package à l’aide d’une action

Vous pouvez utiliser GitHub Actions pour publier automatiquement des packages dans le cadre de votre flux d’intégration continue (CI). Cette approche du déploiement continu (CD) vous permet d’automatiser la création de nouvelles versions de package si le code répond à vos normes de qualité. Par exemple, vous pourriez créer un workflow qui exécute des tests de CI chaque fois qu’un développeur envoie du code à une branche particulière. Si les tests réussissent, le workflow peut publier une nouvelle version de package sur GitHub Packages.

Les étapes de configuration varient selon le client de package. Pour des informations générales sur la configuration d’un workflow pour GitHub Actions, consultez « Configuration d’un workflow ».

L’exemple suivant montre comment utiliser GitHub Actions pour générer votre application , puis créer automatiquement une image Docker et la publier sur GitHub Packages.

Créez un fichier de workflow dans votre dépôt (par exemple .github/workflows/deploy-image.yml), puis ajoutez le YAML suivant :

YAML
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.

# GitHub recommande d’épingler les actions à un SHA de commit.
# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.
# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.

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 }}

Les paramètres pertinents sont expliqués dans le tableau suivant. Pour des informations complètes sur chaque élément d’un workflow, consultez « Syntaxe de workflow pour GitHub Actions ».

```yaml on: push: branches: ['release'] ``` Configure le workflow Create and publish a Docker image pour qu’il s’exécute chaque fois qu’une modification est envoyée (push) à la branche nommée release.
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
Définit deux variables d’environnement personnalisées pour le workflow. Celles-ci sont utilisées pour le domaine Container registry, et un nom pour l’image Docker que ce workflow génère.
jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
Il existe un seul travail dans ce workflow. Il est configuré pour s’exécuter sur la dernière version disponible d’Ubuntu.
```yaml permissions: contents: read packages: write ``` Définit les autorisations accordées au secret GITHUB_TOKEN pour les actions de ce travail.
```yaml - name: Log in to the Container registry uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} ``` Crée une étape appelée Log in to the Container registry, qui se connecte au Registre à l’aide du compte et du mot de passe qui publieront les packages. Une fois publiés, les packages appartiennent au compte défini ici.
```yaml - name: Extract metadata (tags, labels) for Docker id: meta uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} ``` Cette étape utilise docker/metadata-action pour extraire des balises et es étiquettes qui seront appliquées à l’image spécifiée. Le « meta » id permet le référencement de la sortie de cette étape à l’étape suivante. La valeur images fournit le nom de base des balises et étiquettes.
```yaml - name: Build and push Docker image ``` Crée une étape nommée Build and push Docker image. Cette étape s’exécute dans le cadre du travail build-and-push-image.
```yaml uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc ``` Utilise l’action Docker build-push-action pour générer l’image, en fonction du Dockerfile de votre dépôt. Si la build réussit, elle envoie (push) l’image à GitHub Packages.
```yaml with: ``` Envoie les paramètres requis à l’action build-push-action. Ceux-ci sont définis dans les lignes suivantes.
```yaml context: . ``` Définit le contexte de la build comme l’ensemble de fichiers situé dans le chemin d’accès spécifié. Pour plus d’informations, consultez « Utilisation ».
```yaml push: true ``` Envoie (push) cette image au Registre s’il est généré avec succès.
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
Ajoute les balises et étiquettes extraites à l’étape « meta ».

Ce nouveau workflow s’exécute automatiquement chaque fois que vous envoyez une modification à une branche nommée release dans le dépôt. Vous pouvez visualiser la progression sous l’onglet Actions.

Quelques minutes après la fin du workflow, le nouveau package sera visible dans votre dépôt. Pour trouver vos packages disponibles, consultez « Affichage des packages d’un dépôt ».

Installation d’un package à l’aide d’une action

Vous pouvez installer des packages dans le cadre de votre flux de CI en utilisant GitHub Actions. Par exemple, vous pourriez configurer un workflow de façon à ce que, chaque fois qu’un développeur envoie (push) du code à une demande de tirage, le workflow résolve les dépendances en téléchargeant et en installant des packages hébergés par GitHub Packages. Ensuite, le workflow peut exécuter des tests de CI qui nécessitent les dépendances.

L’installation de packages hébergés par GitHub Packages via GitHub Actions nécessite une configuration minimale ou une authentification supplémentaire lorsque vous utilisez le secret GITHUB_TOKEN. Le transfert de données est également gratuit quand une action installe un package. Pour plus d’informations, consultez « À propos de la facturation pour GitHub Packages."

Les étapes de configuration varient selon le client de package. Pour des informations générales sur la configuration d’un workflow pour GitHub Actions, consultez « Configuration d’un workflow ».

Mise à niveau d’un workflow qui accède à un registre avec un personal access token

GitHub Packages prend en charge GITHUB_TOKEN pour faciliter et sécuriser l’authentification dans vos workflows. Si vous utilisez un registre qui prend en charge les autorisations granulaires et que votre workflow utilise un personal access token pour s’authentifier auprès d’un registre, nous vous recommandons vivement de mettre à jour votre workflow pour utiliser GITHUB_TOKEN.

Pour plus d’informations sur le secret GITHUB_TOKEN, consultez « Authentification dans un workflow ».

L’utilisation de GITHUB_TOKEN au lieu d’un personal access token (classic) avec l’étendue repo renforce la sécurité de votre dépôt, car vous n’avez pas besoin d’utiliser un personal access token longue durée qui offre un accès inutile au dépôt où votre workflow est exécuté. Pour plus d’informations sur les meilleures pratiques en matière de sécurité, consultez « Renforcement de la sécurité pour GitHub Actions ».

  1. Accédez à la page de destination de votre package.

  2. Dans la barre latérale de gauche, cliquez sur Accès à Actions. Option « Accès à Actions » dans le menu de gauche

  3. Pour vous assurer que votre package de conteneur a accès à votre workflow, vous devez ajouter le dépôt dans lequel le workflow est stocké à votre conteneur. Cliquez sur Ajouter un dépôt et recherchez le dépôt que vous souhaitez ajouter. Bouton « Ajouter un dépôt »

    Remarque : L’ajout d’un dépôt à votre conteneur via l’option de menu Accès à Actions est différent de la connexion de votre conteneur à un dépôt. Pour plus d’informations, consultez « Garantie de l’accès du workflow à votre package » et « Connexion d’un dépôt à un package ».

  4. Si vous le souhaités, dans le menu déroulant « Rôle », sélectionnez le niveau d’accès par défaut à votre image conteneur que vous aimeriez accorder au dépôt. Niveaux d’accès d’autorisation à donner aux dépôts

  5. Ouvrez votre fichier de workflow. Sur la ligne où vous vous connectez au registre, remplacez votre personal access token par ${{ secrets.GITHUB_TOKEN }}.

Par exemple, ce workflow publie une image Docker dans le Container registry et utilise ${{ secrets.GITHUB_TOKEN }} pour l’authentification.

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