Compartir a través de

Se han solucionado varias solicitudes del Developer Community

  • Artículo

En respuesta a sus comentarios, hemos priorizado varias características que ha solicitado en el Developer Community. En Pipelines, se ha agregado compatibilidad con la función de división de cadenas en la expresión YAML. Además, ahora le permitimos deshabilitar la visualización del último mensaje de confirmación para una ejecución de canalización. En Planes de entrega, aumentamos el límite de equipo de 15 a 20.

Consulte las notas de la versión para obtener más información.

Azure Boards

Azure Pipelines

Azure Boards

Aumentar el límite del equipo de planes de entrega de 15 a 20

Los planes de entrega le permiten ver varios trabajos pendientes y varios equipos en toda la organización. Anteriormente, podía ver 15 trabajos pendientes de equipo, incluida una combinación de trabajos pendientes y equipos de diferentes proyectos. En este sprint hemos aumentado el límite máximo de 15 a 20.

Se ha corregido un error en reporting Work Item Links Get API para devolver el valor remoteUrl correcto para System.LinkTypes.Remote.Related los tipos de vínculo. Antes de esta corrección, devolvíamos el nombre de la organización incorrecto y un identificador de proyecto que faltaba.

Nuevas correcciones de errores del concentrador de paneles

En este sprint corregimos varios errores para new Boards Hub. Puede ver una lista de correcciones de errores en la entrada de blog New Boards Hub, Sprint 209 update ( Actualización de Sprint 209).

Azure Pipelines

Deshabilitación que muestra el último mensaje de confirmación para una ejecución de canalización

Anteriormente, la interfaz de usuario de canalizaciones usada para mostrar el último mensaje de confirmación al mostrar la ejecución de una canalización.

Ejemplo de último mensaje de confirmación

Este mensaje puede resultar confuso, por ejemplo, cuando el código de la canalización de YAML reside en un repositorio diferente del que contiene el código que está compilando. Hemos escuchado sus comentarios del Developer Community nos pide una manera de habilitar o deshabilitar la anexión del mensaje de confirmación más reciente al título de cada ejecución de canalización.

Con esta actualización, hemos agregado una nueva propiedad YAML, denominada appendCommitMessageToRunName, que le permite hacer exactamente eso. De forma predeterminada, la propiedad se establece trueen . Cuando se falseestablece en , la ejecución de la canalización solo mostrará .BuildNumber

Ejemplo de ejecución de canalización con número de compilación

Ejemplo de ejecución de canalización con el último mensaje de confirmación

Recursos consumidos y parámetros de plantilla en pipelines Runs Rest API

La API REST de ejecuciones de canalizaciones extendidas ahora devuelve más tipos de artefactos usados por una ejecución de canalización y los parámetros usados para desencadenar esa ejecución. Se ha mejorado la API para devolver los container recursos y pipeline y los parámetros de plantilla usados en una ejecución de canalización. Ahora puede, por ejemplo, escribir comprobaciones de cumplimiento que evalúen los repositorios, contenedores y otras ejecuciones de canalización usadas por una canalización.

Este es un ejemplo del nuevo cuerpo de respuesta.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Adición de compatibilidad con la función de división de cadenas en expresiones de plantilla YAML

Las canalizaciones de YAML proporcionan maneras cómodas de reducir la duplicación de código, como recorrer en each bucle el valor de una lista o propiedad de un objeto.

A veces, el conjunto de elementos a recorrer en iteración se representa como una cadena. Por ejemplo, cuando la cadena define la lista de entornos en los integration1, integration2que se va a implementar .

A medida que escuchamos los comentarios de la Developer Community, oímos que quería una función de cadena split en expresiones de plantilla YAML.

Ahora, puede split una cadena e iterar sobre each sus subcadenas.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

No sincronizar etiquetas al capturar un repositorio de Git

La tarea de desprotección usa --tags la opción para capturar el contenido de un repositorio de Git. Esto hace que el servidor recupere todas las etiquetas, así como todos los objetos a los que apuntan esas etiquetas. Esto aumenta el tiempo para ejecutar la tarea en una canalización, especialmente si tiene un repositorio grande con una serie de etiquetas. Además, la tarea de desprotección sincroniza etiquetas incluso cuando se habilita la opción de captura superficial, lo que posiblemente derrota su propósito. Para reducir la cantidad de datos capturados o extraídos de un repositorio de Git, ahora hemos agregado una nueva opción a la tarea para controlar el comportamiento de las etiquetas de sincronización. Esta opción está disponible tanto en canalizaciones clásicas como en YAML.

Este comportamiento se puede controlar desde el archivo YAML o desde la interfaz de usuario.

Para no participar en la sincronización de las etiquetas a través del archivo YAML, agregue al fetchTags: false paso de finalización de la compra. Cuando no se especifica la fetchTags opción, es la misma que si fetchTags: true se usa.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Si desea cambiar el comportamiento de las canalizaciones YAML existentes, puede ser más conveniente establecer esta opción en la interfaz de usuario en lugar de actualizar el archivo YAML. Para ir a la interfaz de usuario, abra el editor de YAML para la canalización, seleccione Desencadenadores, procesar y, a continuación, el paso Desprotección.

Si especifica esta configuración tanto en el archivo YAML como en la interfaz de usuario, el valor especificado en el archivo YAML tiene prioridad.

Para todas las canalizaciones nuevas que cree (YAML o clásico), las etiquetas se siguen sincronizando de forma predeterminada. Esta opción no cambia el comportamiento de las canalizaciones existentes. Las etiquetas se seguirán sincronizando en esas canalizaciones a menos que cambie explícitamente la opción como se ha descrito anteriormente.

Programación de brownout actualizada para imágenes de Ubuntu 18.04

Azure Pipelines está en desuso de la imagen ubuntu 18.04 (ubuntu-18.04) en nuestros grupos hospedados. Esta imagen se retirará el 1 de diciembre. Es posible que empiece a ver tiempos de cola más largos.

Para ayudarle a identificar mejor qué canalizaciones usan la imagen ubuntu-18.04, estamos planeando los brownouts. Se producirá un error en los trabajos durante un período de inactividad.

  • Los mensajes de advertencia se muestran en las ejecuciones de canalización mediante la imagen ubuntu-18.04
  • Hay un script disponible para ayudarle a encontrar canalizaciones que usan imágenes en desuso, como ubuntu-18.04.
  • Estamos programando cortos "brownouts". Las ejecuciones de ubuntu-18.04 producirán un error durante el período de brownout. Por lo tanto, se recomienda migrar las canalizaciones antes de los brownouts.

Programación de Brownout (actualizada)

  • 3 de octubre de 12:00 UTC - 3 de octubre de 14:00 UTC
  • 18 de octubre de 14:00 UTC - 18 de octubre de 16:00 UTC
  • 15 de noviembre de 18:00 UTC - 15 de noviembre de 20:00 UTC
  • 30 de noviembre de 20:00 UTC- 30 de noviembre de 22:00 UTC
  • 15 de diciembre de 20:00 UTC - 16 de diciembre de 00:00 UTC
  • 5 de enero de 10.00 UTC - 5 de enero de 14.00 UTC
  • 13 de enero de 12.00 UTC - 13 de enero de 16.00 UTC
  • 18 de enero de 14.00 UTC- 18 de enero de 18.00 UTC
  • 24 de enero de 16.00 UTC - 24 de enero de 20.00 UTC
  • 1 de febrero de 18.00 UTC - 1 de febrero de 22.00 UTC
  • 7 de febrero de 16.00 UTC - 7 de febrero de 22.00 UTC
  • 13 de febrero de 14.00 UTC - 13 de febrero de 22.00 UTC
  • 21 de febrero de 10.00 UTC - 21 de febrero de 22.00 UTC
  • 28 de febrero de 10.00 UTC : 28 de febrero de 22.00 UTC
  • 6 de marzo de 00.00 UTC - 7 de marzo de 00.00 UTC
  • 13 de marzo de 00.00 UTC- 14 de marzo de 00.00 UTC
  • 21 de marzo de 00.00 UTC - 22 de marzo de 00.00 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.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de 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.

Gracias,

Aaron Hallberg