Azure Pipelines: actualización de Sprint 192

Características

Nuevas expresiones condicionales de YAML

Escribir expresiones condicionales en archivos YAML es más fácil con el uso de ${{ else }} expresiones y ${{ elseif }} . A continuación se muestran ejemplos de cómo usar estas expresiones en los archivos de canalizaciones de YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Compatibilidad con comodines en los filtros de ruta de acceso

Las tarjetas comodín se pueden usar al especificar ramas de inclusión y exclusión para desencadenadores de CI o PR en un archivo YAML de canalización. Sin embargo, no se pueden usar al especificar filtros de ruta de acceso. Por ejemplo, no puede incluir todas las rutas de acceso que coincidan con src/app/**/myapp*. Esto ha sido señalado como un inconveniente para varios clientes. Esta actualización rellena este hueco. Ahora, puede usar caracteres comodín (**, *o ?) al especificar filtros de ruta de acceso.

Compatibilidad con varios estados en Bitbucket

Azure Pipelines se integra con repositorios de Bitbucket y admite desencadenadores de CI y PR. Puede configurar varias canalizaciones desde un único repositorio de Bitbucket. Sin embargo, cuando se completaron estas canalizaciones, solo se podía ver un estado en Bitbucket. Hemos oído comentarios de la Comunidad de desarrolladores que solicitan ver el estado de cada canalización por separado en Bitbucket. Con esta actualización, actualizamos nuestras llamadas API a Bitbucket y pasamos información adicional sobre el nombre de la canalización.

estado de compilación

Permitir que los colaboradores omitan la búsqueda de comentarios de solicitudes de incorporación de cambios antes de que se valide la compilación

Al usar Azure Pipelines con repositorios de GitHub, se recomienda no ejecutar automáticamente una canalización de validación de PR para las contribuciones recibidas de un repositorio bifurcado. Este es el procedimiento recomendado: uno de los colaboradores del repositorio debe revisar el cambio y luego añadir un comentario al PR para desencadenar la canalización. Para configurar estas opciones, seleccione el menú Desencadenadores (para canalizaciones YAML) o la pestaña Desencadenadores (para canalizaciones de compilación clásicas) en el editor web de canalización. En lugar de requerir que las solicitudes de incorporación de cambios procedentes de un fork sean primero revisadas por un miembro del equipo, también puede aplicar esta política solo en contribuciones que provengan de personas ajenas al equipo.

Con esta actualización, le permitimos omitir la búsqueda de un comentario de solicitud de incorporación de cambios de las contribuciones recibidas por cualquier colaborador. Como no ser miembro del equipo, al crear una bifurcación y crear una solicitud de incorporación de cambios en el repositorio principal, no se te considera colaborador en el repositorio principal hasta que se fusione tu solicitud de incorporación de cambios. Una vez que tu Pull Request sea fusionado, se te considerará un colaborador. Al seleccionar la nueva opción que se muestra a continuación, cuando un miembro que no es miembro del equipo envía una solicitud de incorporación de cambios desde una bifurcación por primera vez, alguien del equipo tendría que revisar la solicitud de incorporación de cambios y agregar un comentario para desencadenar la canalización. Sin embargo, una vez combinada la solicitud de incorporación de cambios, las contribuciones adicionales realizadas por ese miembro que no sea miembro del equipo desencadenarán directamente la canalización sin esperar un comentario de solicitud de incorporación de cambios.

Requerir un comentario de un miembro del equipo antes de crear un pull request

Windows Server 2022 con Visual Studio 2022 ya está disponible en agentes hospedados por Microsoft (versión preliminar)

Windows Server 2022 y Visual Studio Enterprise 2022 Preview ya están disponibles en versión preliminar en agentes hospedados por Microsoft. Puede usarlo haciendo referencia a windows-2022 como imagen en la tubería.

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

Al hacer referencia a "windows-latest pool" en las canalizaciones de YAML, seguirá refiriéndose a windows-2019 y no a windows-2022, ya que windows-2022 está en versión preliminar.

La imagen de la cadena de herramientas del Windows Server 2022 tiene diferentes herramientas disponibles y sus versiones al compararse con el Windows Server 2019. Puede ver los detalles en el comunicado de anuncio del software y en el repositorio de documentación de entornos virtuales.

Disponibilidad general de macOS 11 en agentes hospedados por Microsoft

MacOS 11 ya está disponible con carácter general en agentes hospedados por Microsoft. Puede usarlo referenciando macos-11 como imagen en su flujo de trabajo.

pool:
  vmImage: macos-11

Eliminación de la imagen de Ubuntu 16.04 en agentes hospedados por Microsoft

Como se anunció anteriormente, se quitará la imagen de Ubuntu 16.04 de los agentes hospedados por Microsoft el 20 de septiembre de 2021. El soporte tradicional de 5 años de Ubuntu 16.04 por Canonical finalizó en abril de 2021. Deberá migrar las canalizaciones de Ubuntu 16.04 a Ubuntu 18.04 o Ubuntu-latest, que se ejecutarán en Ubuntu 20.04 LTS.

Las compilaciones que usan Ubuntu-16.04 ya tienen una advertencia que se está generando. Para asegurarnos de que todos conozcan este cambio, programamos 2 cortos "brownouts". Las compilaciones de Ubuntu 16.04 fallarán durante el período de brownout. Por lo tanto, se recomienda migrar los flujos de trabajo antes del 6 de septiembre de 2021.

Los brownouts están programados para las fechas y horas siguientes (tenga en cuenta que se han ampliado por una hora a partir de las horas anunciadas anteriormente): 6 de septiembre de 2021 4:00 UTC : 10:00PM UTC 14 de septiembre de 2021 4:00 UTC – 10:00PM UTC

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Ir a Azure DevOps

Cómo proporcionar comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú ayuda para notificar un problema o proporcionar una sugerencia.

Hacer una sugerencia

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

  • Se actualizó por última vez el