Partager via


Publier des packages NuGet avec Azure Pipelines (YAML/Classic)

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Avec Azure Pipelines, vous pouvez utiliser des pipelines classiques ou YAML pour publier vos packages NuGet vers votre flux Azure Artifacts, des flux externes ou des registres publics tels que nuget.org. Dans cet article, vous apprendrez à :

  • Générer un package NuGet dans Azure Pipelines.
  • Publier des packages sur des flux internes et externes.
  • Publier des packages sur NuGet.org

Prérequis

Créer un package NuGet

Il existe plusieurs façons de créer vos packages NuGet, notamment en utilisant la CLI dotnet ou nuget.exe pour empaqueter vos packages. Si vous utilisez déjà MSBuild ou d'autres tâches pour créer vos packages, vous pouvez sauter cette section et passer à la suivante.

Pour créer un package NuGet, ajoutez l'extrait suivant à votre fichier YAML. Pour plus d’informations, consultez Tâche NuGet.

- task: NuGetCommand@2
  inputs:
    command: pack
    packagesToPack: '**/*.csproj'
    packDestination: '$(Build.ArtifactStagingDirectory)'
  • packagesToPack : le modèle que la tâche utilise pour rechercher les répertoires csproj à empaqueter.
  • packDestination : répertoire dans lequel les packages sont créés. Si la valeur est vide, les packages sont créés à la racine de la source.

Contrôle de version des packages

Les packages NuGet sont définis par leur nom et leur numéro de version. L'utilisation de la version sémantique est une approche recommandée pour gérer efficacement les versions des packages. Semantic Versioning se compose de trois éléments numériques : Major, Minor et Patch.

Le numéro de patch est incrémenté après la correction d'un bogue. Lors de la publication d'une nouvelle fonctionnalité rétrocompatible, la version Minor est incrémentée et la version Patch est remise à 0. Inversement, lors d'une modification incompatible avec les versions précédentes, la version majeure est incrémentée et les versions mineure et patch sont réinitialisées à 0.

Semantic Versioning prend également en charge les étiquettes de pré-version pour baliser les packages. Il suffit d'ajouter un trait d'union suivi de la balise de pré-version, par exemple : 1.0.0-beta.

Azure Pipelines prend en charge Semantic Versioning et propose les options de configuration suivantes pour les tâches NuGet :

  • Utiliser la date et l'heure (Classic) | byPrereleaseNumber (YAML) : La version de votre package suit le format Major.Minor.Patch-ci-datetime, où vous pouvez personnaliser les valeurs Major, Minor et Patch.

  • Utiliser une variable d'environnement (Classique) | byEnvVar (YAML) : La version de votre package est définie par la valeur de la variable d'environnement spécifiée.

  • Utiliser le numéro de build (Classique) | byBuildNumber (YAML) : La version de votre package correspond au numéro de build. Veillez à définir le format du numéro de build dans votre pipeline Options comme $(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r). Pour spécifier le format en YAML, ajoutez une propriété name: à la racine de votre pipeline et définissez votre format.

Voici un exemple montrant comment utiliser le versionnement par date et heure pour générer un package conforme à SemVer formaté comme suit : Major.Minor.Patch-ci-datetime.

variables:
  Major: '1'
  Minor: '0'
  Patch: '0'

steps:
- task: NuGetCommand@2
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

Remarque

Les packages DotNetCore et DotNetStandard doivent être empaquetés avec la tâche DotNetCoreCLI@2 pour éviter System.InvalidCastExceptions. Pour plus d'informations, consultez la tâche CLI .NET Core.

task: DotNetCoreCLI@2
inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

Publier des packages dans des flux internes

Remarque

Pour publier vos packages dans un flux avec Azure Pipelines, assurez-vous que les identités du service de build de la collection de projets et du service de build de votre projet disposent du rôle d'éditeur de flux (contributeur) dans les paramètres de votre flux. Consultez la section Gérer les permissions pour plus de détails.

steps:
- task: NuGetAuthenticate@1
  displayName: 'NuGet Authenticate'
- task: NuGetCommand@2
  displayName: 'NuGet push'
  inputs:
    command: push
    publishVstsFeed: '<projectName>/<feed>'
    allowPackageConflicts: true

Publier des packages vers des flux externes

Pour publier vos packages vers des flux NuGet externes ou des registres publics, tels que les flux d'autres organisations Azure DevOps ou nuget.org, créez d'abord une connexion de service pour vous authentifier auprès du service concerné :

  1. Dans votre projet Azure DevOps, allez à Paramètres du projet> > Connexions de service>

  2. Sélectionnez Nouvelle connexion de service>NuGet>Suivant.

  3. Remplissez les champs requis et sélectionnez Sauvegarder lorsque vous avez terminé. Pour plus d’informations, consultez Gérer les connexions de service.

Remarque

La tâche NuGetAuthenticate@1 prend en charge les connexions de service avec l'authentification de base, mais ne prend pas en charge l'authentification ApiKey. Pour utiliser l'authentification ApiKey, utilisez la tâche NuGetCommand@2.

Pour publier vos packages NuGet vers un flux d'une autre organisation, ajoutez le snippet suivant à votre pipeline YAML :

  • En utilisant la tâche de ligne de commande et NuGet.exe :

      - task: NuGetAuthenticate@1
        inputs:
          nuGetServiceConnections: <NAME_OF_YOUR_SERVICE_CONNECTION>
    
      - script: |
          nuget push <PACKAGE_PATH> -src https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json -ApiKey <ANY_STRING>
        displayName: "Push"          
    
  • En utilisant la tâche de ligne de commande et dotnet :

        - task: NuGetAuthenticate@1
          inputs:
            nuGetServiceConnections: <NAME_OF_YOUR_SERVICE_CONNECTION>
    
        - script: |
            dotnet build <CSPROJ_PATH> --configuration <CONFIGURATION>
            dotnet pack <CSPROJ_PATH> -p:PackageVersion=<YOUR_PACKAGE_VERSION> --output <OUTPUT_DIRECTORY> --configuration <CONFIGURATION>
            dotnet nuget push <PACKAGE_PATH> --source https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json --api-key <ANY_STRING>
          displayName: "Build, pack and push"          
      ```
    
    

Remarque

Le ApiKey est obligatoire, mais vous pouvez utiliser n'importe quelle chaîne lorsque vous publiez vers un flux Azure Artifacts.

Publier sur NuGet.org

  1. Connectez-vous à votre compte nuget.org et générez une clé API.

  2. Accédez à votre projet Azure DevOps, puis sélectionnez icône d’engrenageParamètres du projet.

  3. Sélectionnez Connexions de service, puis Nouvelle connexion de service.

  4. Sélectionnez NuGet, puis sélectionnez Suivant.

  5. Sélectionnez ApiKey comme méthode d'authentification et utilisez l'URL suivante pour votre URL de flux : https://api.nuget.org/v3/index.json.

  6. Saisissez la clé ApiKey générée précédemment, puis fournissez un nom de connexion de service.

  7. Sélectionnez Accorder une autorisation d’accès à tous les pipelines, puis Enregistrer lorsque vous avez terminé. Notez que vous devez avoir le rôle d'administrateur de la connexion de service pour sélectionner cette option.

steps:
- task: NuGetCommand@2
  displayName: 'NuGet push'
  inputs:
    command: push
    nuGetFeedType: external
    publishFeedCredentials: nuget.org