Compartir a través de

Publicación de paquetes NuGet con Azure Pipelines (YAML/clásico)

  • Artículo

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

Con Azure Pipelines, puede usar canalizaciones clásicas o YAML para publicar los paquetes NuGet en la fuente de Azure Artifacts, fuentes externas o registros públicos como nuget.org. En este artículo, obtendrá información sobre cómo realizar lo siguiente:

  • Generar un paquete NuGet en Azure Pipelines
  • Publicar paquetes en fuentes internas y externas
  • Publicar paquetes en NuGet.org

Requisitos previos

Creación de un paquete NuGet

Hay varias maneras de crear los paquetes NuGet, como usar la CLI de dotnet o nuget.exe para empaquetar los paquetes. Si ya usa MSBuild u otras tareas para crear los paquetes, puede omitir esta sección y continuar con la siguiente.

Para crear un paquete NuGet, agregue el siguiente fragmento de código al archivo YAML. Consulte Tarea de NuGet para obtener más detalles.

- task: NuGetCommand@2
  inputs:
    command: pack
    packagesToPack: '**/*.csproj'
    packDestination: '$(Build.ArtifactStagingDirectory)'
  • packagesToPack: el patrón que usa la tarea para buscar directorios csproj para empaquetar.
  • packDestination: directorio donde se crean los paquetes. Si está vacía, los paquetes se crearán en la raíz de origen.

Control de versiones de paquetes

Los paquetes NuGet se definen por sus nombres y números de versión. El uso del control de versiones semánticas es un enfoque recomendado para administrar eficazmente versiones de paquete. Las versiones semánticas constan de tres componentes numéricos: principal, secundaria y revisión.

El número de revisión se incrementa después de corregir un error. Al publicar una nueva característica compatible con versiones anteriores, se incrementa la versión secundaria y se restablece la versión de revisión a 0. Y a la inversa, cuando se realiza un cambio incompatible con versiones anteriores, se incrementa la versión principal y se restablecen las versiones secundaria y de revisión a 0.

El control de versiones semánticas también admite el uso de etiquetas de versión preliminar para etiquetar paquetes. Simplemente anexe un guion seguido de la etiqueta de versión preliminar, por ejemplo: 1.0.0-beta.

Azure Pipelines admite el control de versiones semánticas y ofrece las siguientes opciones de configuración para las tareas de NuGet:

  • Uso de la fecha y hora (clásico) | byPrereleaseNumber (YAML): la versión del paquete sigue el formato: Major.Minor.Patch-ci-datetime , donde tiene la flexibilidad de personalizar los valores de principal, secundaria y revisión.

  • Uso de una variable de entorno (clásico) | byEnvVar (YAML): la versión del paquete se establece en el valor de la variable de entorno especificada.

  • Uso del número de compilación (clásico) | byBuildNumber (YAML): la versión del paquete se establece en el número de compilación. Asegúrese de definir el formato del número de compilación en las Opciones de canalización como $(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r). Para especificar el formato en YAML, agregue una propiedad name: en la raíz de la canalización y defina el formato.

A continuación se muestra un ejemplo que muestra cómo usar el control de versiones de fecha y hora para generar un paquete compatible con SemVer con el formato: 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)'

Nota:

Los paquetes DotNetCore y DotNetStandard deben empaquetarse con la tarea DotNetCoreCLI@2 para evitar System.InvalidCastExceptions. Para obtener más información, consulte Tarea de la CLI de .NET Core.

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

Publicación de paquetes en fuentes internas

Nota:

Para publicar los paquetes en una fuente mediante Azure Pipelines, asegúrese de que tanto el Servicio de compilación de colecciones de proyectos como las identidades de Servicio de compilación del proyecto tengan el rol de Publicador de fuentes (colaborador) asignado en la configuración de la fuente. Consulte Administración de permisos para obtener más información.

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

Publicación de paquetes en fuentes externas

Para publicar los paquetes en fuentes de NuGet externas o registros públicos, como fuentes de otras organizaciones de Azure DevOps o nuget.org, primero debe crear una conexión de servicio para autenticarse con el servicio correspondiente:

  1. En el proyecto de Azure DevOps, acceda a Configuración del proyecto>Conexiones de servicio>.

  2. Seleccione Nueva conexión de servicio>NuGet>Siguiente.

  3. Rellene los campos necesarios y seleccione Guardar cuando haya terminado. Consulte Administración de conexiones de servicio para obtener más detalles.

Nota:

La tarea NuGetAuthenticate@1 admite conexiones de servicio con autenticación básica, pero no admite la autenticación Apikey. Para usar la autenticación ApiKey, debe usar la tarea NuGetCommand@2 en su lugar.

Para publicar los paquetes NuGet en una fuente de otra organización, agregue el siguiente fragmento de código a la canalización de YAML:

  • Con la tarea de línea de comandos y 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"

  • Con la tarea de línea de comandos y 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"          
  ```

Nota:

ApiKey es necesario, pero puede usar cualquier cadena al publicar en una fuente de Azure Artifacts.

Publicar en NuGet.org

  1. Inicie sesión en la cuenta de nuget.org y genere una clave de API.

  2. Vaya al proyecto de Azure DevOps y seleccione el icono de engranajeConfiguración del proyecto.

  3. Seleccione Conexiones de servicio y, a continuación, seleccione Nueva conexión de servicio.

  4. Seleccione NuGet y después Siguiente.

  5. Seleccione ApiKey como método de autenticación y use la siguiente dirección URL para la URL de la fuente: https://api.nuget.org/v3/index.json.

  6. Escriba la ApiKey que generó anteriormente y, a continuación, indique un nombre de conexión de servicio.

  7. Seleccione Conceder permiso de acceso a todas las canalizaciones y, a continuación, seleccione Guardar cuando haya terminado. Tenga en cuenta que, para seleccionar esta opción, necesita el rol de administrador de conexión de servicio.

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