Enterprise Server 3.20 est actuellement disponible en tant que version candidate.

Utilisation du registre NuGet

Vous pouvez configurer l’interface de ligne de commande (CLI) dotnet pour publier des packages NuGet sur GitHub Packages et utiliser des packages stockés sur GitHub Packages en tant que dépendances dans un .NET project.

Dans cet article

Remarque

Ce type de package peut ne pas être disponible pour votre instance, car les administrateurs de site peuvent activer ou désactiver chaque type de package pris en charge. Pour plus d’informations, consultez « Configuration de la prise en charge de l’écosystème de packages pour votre entreprise ».

Authentification auprès de GitHub Packages

Remarque

GitHub Packages prend uniquement en charge l’authentification à l’aide d’un personal access token (classic). Pour plus d’informations, consultez « Gestion de vos jetons d’accès personnels ».

Vous avez besoin d’un jeton d’accès pour publier, installer et supprimer des packages privés, internes et publics.

Vous pouvez utiliser un personal access token (classic) pour vous authentifier auprès de GitHub Packages ou de l’API GitHub. Quand vous créez un personal access token (classic), vous pouvez l’attribuer à différentes étendues selon vos besoins. Pour plus d’informations sur les étendues liées aux packages pour un personal access token (classic), consultez À propos des autorisations pour les packages GitHub.

Pour vous authentifier sur un registre GitHub Packages dans un workflow GitHub Actions, vous pouvez utiliser :

  • GITHUB_TOKEN pour publier des packages associés au dépôt du workflow.
  • Un personal access token (classic) avec au moins read:packages la possibilité d'installer des paquets associés à d'autres référentiels privés (GITHUB_TOKEN peut être utilisé si le référentiel a un accès en lecture au paquet. Consultez Configuration du contrôle d’accès et de la visibilité d’un package.

Authentification dans un workflow GitHub Actions

Utilisez la commande suivante pour vous authentifier auprès de GitHub Packages dans un workflow GitHub Actions avec GITHUB_TOKEN au lieu de coder en dur un personal access token dans un fichier nuget.config dans le dépôt :

dotnet nuget add source --username USERNAME --password ${{ secrets.GITHUB_TOKEN }} --store-password-in-clear-text --name github "https://nuget.HOSTNAME/NAMESPACE/index.json"

Remplacez NAMESPACE par le nom du compte personnel ou de l’organisation propriétaire du dépôt où vos packages sont hébergés.

Remplacez USERNAME par le nom d’utilisateur à utiliser lors de la connexion à une source authentifiée.

Pour plus d’informations sur GITHUB_TOKEN utilisé dans les flux de travail GitHub Actions, consultez Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail.

Authentification avec un personal access token

Remarque

GitHub Packages prend uniquement en charge l’authentification à l’aide d’un personal access token (classic). Pour plus d’informations, consultez « Gestion de vos jetons d’accès personnels ».

Vous avez besoin d’un jeton d’accès pour publier, installer et supprimer des packages privés, internes et publics.

Vous pouvez utiliser un personal access token (classic) pour vous authentifier auprès de GitHub Packages ou de l’API GitHub. Quand vous créez un personal access token (classic), vous pouvez l’attribuer à différentes étendues selon vos besoins. Pour plus d’informations sur les étendues liées aux packages pour un personal access token (classic), consultez À propos des autorisations pour les packages GitHub.

Pour vous authentifier sur un registre GitHub Packages dans un workflow GitHub Actions, vous pouvez utiliser :

  • GITHUB_TOKEN pour publier des packages associés au dépôt du workflow.
  • Un personal access token (classic) avec au moins read:packages la possibilité d'installer des paquets associés à d'autres référentiels privés (GITHUB_TOKEN peut être utilisé si le référentiel a un accès en lecture au paquet. Consultez Configuration du contrôle d’accès et de la visibilité d’un package.

Vous devez utiliser un personal access token (classic) avec les étendues appropriées pour publier et installer des packages dans GitHub Packages. Pour plus d’informations, consultez « Introduction aux packages GitHub ».

Pour vous authentifier auprès de GitHub Packages avec l’interface de ligne de commande dotnet, créez un fichier nuget.config dans votre répertoire project spécifiant GitHub Packages en tant que source sous packageSources pour le client CLI dotnet.

Vous devez remplacer : * USERNAME avec le nom de votre compte personnel sur GitHub.

  •           `TOKEN` par votre personal access token (classic).

  •           `NAMESPACE` par le nom du compte personnel ou de l’organisation qui possède le référentiel où vos packages sont hébergés.

  •           `HOSTNAME` par le nom d’hôte pour votre instance GitHub Enterprise Server.

Si l’isolation de sous-domaine est activée pour votre instance :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <clear />
        <add key="github" value="https://nuget.HOSTNAME/NAMESPACE/index.json" />
    </packageSources>
    <packageSourceCredentials>
        <github>
            <add key="Username" value="USERNAME" />
            <add key="ClearTextPassword" value="TOKEN" />
        </github>
    </packageSourceCredentials>
</configuration>

Si l’isolation de sous-domaine est désactivée pour votre instance :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <clear />
        <add key="github" value="https://HOSTNAME/_registry/nuget/NAMESPACE/index.json" />
    </packageSources>
    <packageSourceCredentials>
        <github>
            <add key="Username" value="USERNAME" />
            <add key="ClearTextPassword" value="TOKEN" />
        </github>
    </packageSourceCredentials>
</configuration>

Publication d'un package

Vous pouvez publier un package sur GitHub Packages en vous authentifiant avec un fichier nuget.config, en utilisant --api-keyl’option de ligne de commande avec votre GitHub personal access token (classic) ou en utilisant une commande qui peut être directement exécutée à partir de la ligne de commande à l’aide de dotnet l’interface de ligne de commande (CLI).

Remplacez OWNER par votre nom d’utilisateur ou votre nom d’entreprise et YOUR_GITHUB_PAT par votre personal access token.

dotnet nuget add source --username OWNER --password YOUR_GITHUB_PAT --store-password-in-clear-text --name github "https://nuget.HOSTNAME/OWNER/index.json"

Publication d’un package en utilisant un personal access token GitHub en tant que clé API

Si vous n'avez pas encore de personal access token à utiliser pour votre compte sur GitHub, voir Gestion de vos jetons d’accès personnels.

  1. Créez un nouveau projet. Remplacez PROJECT_NAME par le nom que vous souhaitez donner à la project.

    dotnet new console --name PROJECT_NAME

  2. Empaquetez le projet.

    dotnet pack --configuration Release

  3. Publiez le package en utilisant votre personal access token comme clé API. Remplacez PROJECT_NAME par le nom du project, 1.0.0 par le numéro de version du package et YOUR_GITHUB_PAT par votre personal access token.

    dotnet nuget push "bin/Release/PROJECT_NAME.1.0.0.nupkg" --api-key YOUR_GITHUB_PAT --source "github"

Après avoir publié un package, vous pouvez l'afficher sur GitHub. Pour plus d’informations, consultez « Affichage de packages ».

Publication d’un package à l’aide d’un fichier nuget.config

Lors de la publication, le OWNER du dépôt spécifié dans votre fichier .csproj doit correspondre au NAMESPACE que vous utilisez dans votre fichier d’authentification nuget.config. Spécifiez ou incrémentez le numéro de version dans votre fichier .csproj, puis utilisez la commande dotnet pack pour créer un fichier .nuspec pour cette version. Pour plus d’informations sur la création de votre package, consultez Créer et publier un package dans la documentation Microsoft.

  1. Authentifiez-vous sur GitHub Packages. Pour plus d’informations, consultez Authentification auprès de GitHub Packages.

  2. Créez un projet. Remplacez PROJECT_NAME par le nom que vous souhaitez donner à la project.

    dotnet new console --name PROJECT_NAME

  3. Ajoutez les informations spécifiques de votre projet au fichier de votre projet, qui se termine par .csproj. Veillez à remplacer :

    •      `1.0.0` avec le numéro de version du paquet.

    •      `OWNER` par le nom du compte personnel ou de l’organisation propriétaire du dépôt dans lequel vous souhaitez publier votre package.

    •      `REPOSITORY` par le nom du dépôt auquel vous souhaitez connecter votre package.

    •           `HOSTNAME` par le nom d’hôte pour votre instance GitHub Enterprise Server.

    <Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PackageId>PROJECT_NAME</PackageId>
    <Version>1.0.0</Version>
    <Authors>AUTHORS</Authors>
    <Company>COMPANY_NAME</Company>
    <PackageDescription>PACKAGE_DESCRIPTION</PackageDescription>
    <RepositoryUrl>https://HOSTNAME/OWNER/REPOSITORY</RepositoryUrl>
  </PropertyGroup>

</Project>

  4. Emballer le projet.

    dotnet pack --configuration Release

  5. Publiez le package avec la key que vous avez spécifiée dans le fichier nuget.config. Remplacez PROJECT_NAME par le nom du project, puis remplacez 1.0.0 par le numéro de version du package.

    dotnet nuget push "bin/Release/PROJECT_NAME.1.0.0.nupkg" --source "github"

Après avoir publié un package, vous pouvez l'afficher sur GitHub. Pour plus d’informations, consultez « Affichage de packages ».

Publication de plusieurs packages sur le même dépôt

Pour connecter plusieurs packages au même référentiel, utilisez la même URL de référentiel GitHub dans les champs RepositoryURL dans tous les fichiers .csproj project. GitHub correspond au dépôt en fonction de ce champ.

L’exemple suivant publie les projets MY_APP et MY_OTHER_APP dans le même dépôt :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PackageId>MY_APP</PackageId>
    <Version>1.0.0</Version>
    <Authors>Octocat</Authors>
    <Company>GitHub</Company>
    <PackageDescription>This package adds a singing Octocat!</PackageDescription>
    <RepositoryUrl>https://HOSTNAME/my-org/my-repo</RepositoryUrl>
  </PropertyGroup>

</Project>

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PackageId>MY_OTHER_APP</PackageId>
    <Version>1.0.0</Version>
    <Authors>Octocat</Authors>
    <Company>GitHub</Company>
    <PackageDescription>This package adds a dancing Octocat!</PackageDescription>
    <RepositoryUrl>https://HOSTNAME/my-org/my-repo</RepositoryUrl>
  </PropertyGroup>

</Project>

Installation d’un package

L’utilisation de packages depuis GitHub dans votre projet est similaire à l’utilisation de packages depuis nuget.org. Ajoutez vos dépendances de packages à votre fichier .csproj en spécifiant le nom et la version du package. Pour plus d’informations sur l’utilisation d’un fichier .csproj dans votre projet, consultez Travailler avec des packages NuGet dans la documentation Microsoft.

  1. Authentifiez-vous sur GitHub Packages. Pour plus d’informations, consultez Authentification auprès de GitHub Packages.

  2. Pour utiliser un package, ajoutez ItemGroup et configurez le champ PackageReference dans le fichier .csproj project. Remplacez la valeur PACKAGE_NAME dans Include="PACKAGE_NAME" par votre dépendance de package et remplacez la valeur X.X.X dans Version="X.X.X" par la version du package que vous voulez utiliser :

    <Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PackageId>My-app</PackageId>
    <Version>1.0.0</Version>
   <Authors>Octocat</Authors>
    <Company>GitHub</Company>
   <PackageDescription>This package adds an Octocat!</PackageDescription>
    <RepositoryUrl>https://HOSTNAME/OWNER/REPOSITORY</RepositoryUrl>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="PACKAGE_NAME" Version="X.X.X" />
  </ItemGroup>

</Project>

  3. Installez les packages avec la commande restore.

    dotnet restore

Dépannage

La poussée de votre package NuGet peut échouer si le RepositoryUrl dans .csproj n’est pas défini sur le dépôt attendu.

Si vous utilisez un fichier nuspec, vérifiez qu’il contient un élément repository avec les attributs type et url requis.

Si vous utilisez un GITHUB_TOKEN pour vous authentifier auprès d'un registre GitHub Packages au sein d'un workflow GitHub Actions, le jeton ne peut pas accéder aux packages privés basés sur un autre référentiel que celui dans lequel le flux de travail s'exécute. Pour accéder aux packages associés à d'autres dépôts, générez plutôt un personal access token (classic) avec l'étendue read:packages et transmettez ce jeton comme un secret.

Erreurs 403 intermittentes lors de la restauration de packages publics

Si vous utilisez GitHub Packages en même temps que nuget.org et que vous rencontrez des erreurs intermittentes 403 Interdites lors de la restauration de packages publics standard (par exemple Microsoft.Extensions.*), cela peut se produire, car NuGet interroge toutes les sources de package configurées pour chaque package. Si GitHub Packages l’authentification échoue temporairement, elle peut bloquer l’intégralité de la restauration, même pour les packages qui n’existent pas sur GitHub Packages.

Pour éviter cela, utilisez le mappage de source de package NuGet pour router les packages vers des sources spécifiques.

Remplacez : * NAMESPACE avec le nom du compte personnel ou de l’organisation possédant votre GitHub Packages flux de NuGet.

  •           `PACKAGE-ID-PREFIX` par le préfixe d’ID de package NuGet que vous utilisez pour les packages hébergés sur GitHub Packages. Si vous utilisez plusieurs préfixes, ajoutez des entrées supplémentaires `<package>` pour chaque préfixe.

  •           `HOSTNAME` par le nom d’hôte pour votre instance GitHub Enterprise Server.

Si l’isolation de sous-domaine est activée pour votre instance :

<configuration>
    <packageSources>
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
        <add key="github" value="https://nuget.HOSTNAME/NAMESPACE/index.json" />
    </packageSources>
    <packageSourceMapping>
        <packageSource key="nuget.org">
            <package pattern="*" />
        </packageSource>
        <packageSource key="github">
            <package pattern="PACKAGE-ID-PREFIX.*" />
        </packageSource>
    </packageSourceMapping>
</configuration>

Si l’isolation de sous-domaine est désactivée pour votre instance :

<configuration>
    <packageSources>
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
        <add key="github" value="https://HOSTNAME/_registry/nuget/NAMESPACE/index.json" />
    </packageSources>
    <packageSourceMapping>
        <packageSource key="nuget.org">
            <package pattern="*" />
        </packageSource>
        <packageSource key="github">
            <package pattern="PACKAGE-ID-PREFIX.*" />
        </packageSource>
    </packageSourceMapping>
</configuration>

NuGet utilise le modèle de correspondance le plus spécifique. Par conséquent, les packages correspondants PACKAGE-ID-PREFIX.* sont extraits uniquement à partir de GitHub Packages, tandis que tous les autres packages sont extraits de nuget.org. Cela permet également d’éviter les attaques de confusion des dépendances en garantissant que vos packages privés ne peuvent provenir que de votre flux GitHub Packages.

Pour approfondir

  •         [AUTOTITLE](/packages/learn-github-packages/deleting-and-restoring-a-package)