Compartir a través de

Compatibilidad con expresiones de plantilla en definiciones de recursos de contenedor y repositorio

  • Artículo

Con esta actualización, se incluyó compatibilidad con expresiones de plantilla en definiciones de recursos de repositorio y contenedor. Ahora puede usar expresiones de plantilla al definir la ref propiedad de un repository recurso en una canalización YAML para elegir la rama de un recurso de repositorio. Además, hemos agregado compatibilidad con expresiones de plantilla al definir las endpointpropiedades , volumes, portsy options de un recurso en una container canalización YAML.

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

Azure Boards

Azure Pipelines

Azure Boards

Anteriormente, cambiar un vínculo de elemento de trabajo requiere al menos tres pasos para completar. Por ejemplo, para cambiar un vínculo primario a un vínculo relacionado, debe copiar el identificador del elemento de trabajo, quitar el vínculo primario, agregar un nuevo vínculo existente de tipo relacionado y, por último, pegar el identificador copiado y guardarlo. Es un proceso complicado.

Hemos resuelto el problema al permitirle editar y cambiar el tipo de vínculo directamente. Puede cambiar rápidamente el tipo de vínculo en un solo paso.

Gif para editar tipos de vínculo de elemento de trabajo de demostración.

Nota:

Esta característica solo estará disponible con la versión preliminar de New Boards Hubs.

Creación de un punto de conexión DE REST de consulta temporal

Hemos visto varias instancias de autores de extensiones que intentan ejecutar consultas no guardadas pasando la instrucción Lenguaje de consulta de elementos de trabajo (WIQL) a través de la cadena de consulta. Esto funciona bien a menos que tenga una instrucción WIQL grande que alcance los límites del explorador en la longitud de la cadena de consulta. Para resolver esto, hemos creado un nuevo punto de conexión REST para permitir que los autores de herramientas generen una consulta temporal. El uso del identificador de la respuesta para pasar a través de querystring elimina este problema.

Obtenga más información en la página de documentación de la API REST de consultas temporales.

API de eliminación por lotes (versión preliminar privada)

Actualmente, la única manera de quitar elementos de trabajo de la papelera de reciclaje es usar esta API REST para eliminarlos de uno en uno. Esto puede ser un proceso lento y está sujeto a la limitación de velocidad al intentar realizar cualquier tipo de limpieza masiva. En respuesta, hemos agregado un nuevo punto de conexión de API REST para eliminar o destruir elementos de trabajo por lotes.

Si está interesado en participar en una versión preliminar privada de este nuevo punto de conexión, envíenos un correo electrónico directamente.

@CurrentIteration macro en Planes de entrega

Con esta actualización, hemos agregado compatibilidad con la @CurrentIteration macro para estilos en Planes de entrega. Esta macro le permitirá obtener la iteración actual del contexto del equipo de cada fila del plan.

Gif para demostración de la macro CurrentIteration en Planes de entrega.

Azure Pipelines

Expresiones de plantilla en la definición de recursos del repositorio

Se ha agregado compatibilidad con expresiones de plantilla al definir la ref propiedad de un repository recurso en una canalización YAML. Esta fue una característica muy solicitada por nuestra Comunidad de desarrolladores.

Existen casos de uso en los que desea que la canalización consulte diferentes ramas del mismo recurso de repositorio.

Por ejemplo, supongamos que tiene una canalización que compila su propio repositorio y, para ello, debe consultar una biblioteca de un repositorio de recursos. Además, supongamos que quiere que la canalización consulte la misma rama de biblioteca que está usando. Por ejemplo, si la canalización se ejecuta en la main rama, debe consultar la main rama del repositorio de biblioteca. Si las canalizaciones se ejecutan en la dev rama, debe desactive la rama de dev biblioteca.

Hasta hoy, tenía que especificar explícitamente la rama para desasecar y cambiar el código de canalización cada vez que cambia la rama.

Ahora, puede usar expresiones de plantilla para elegir la rama de un recurso de repositorio. Consulte el ejemplo siguiente de código YAML que se va a usar para las ramas que no son principales de la canalización:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Al ejecutar la canalización, puede especificar la rama que se va a descarcarcar para el library repositorio.

Especificar la versión de una plantilla que se va a extender en tiempo de cola de compilación

Las plantillas representan una excelente manera de reducir la duplicación de código y mejorar la seguridad de las canalizaciones.

Un caso de uso popular es hospedar plantillas en su propio repositorio. Esto reduce el acoplamiento entre una plantilla y las canalizaciones que lo extienden y facilita la evolución de la plantilla y las canalizaciones de forma independiente.

Considere el ejemplo siguiente, en el que se usa una plantilla para supervisar la ejecución de una lista de pasos. El código de plantilla se encuentra en el Templates repositorio.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Supongamos que tiene una canalización YAML que extiende esta plantilla, ubicada en el repositorio FabrikamFiber. Hasta hoy, no era posible especificar dinámicamente la ref propiedad del recurso del templates repositorio al usar el repositorio como origen de plantilla. Esto significaba que tenía que cambiar el código de la canalización si quería que la canalización: ampliar una plantilla de otra rama extienda una plantilla desde el mismo nombre de rama que la canalización, independientemente de la rama que ejecutó la canalización.

Con la introducción de expresiones de plantilla en la definición de recursos del repositorio, puede escribir la canalización de la siguiente manera:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Al hacerlo, la canalización extenderá la plantilla en la misma rama que la rama en la que se ejecuta la canalización, por lo que puede asegurarse de que las ramas de la canalización y de la plantilla siempre coinciden. Es decir, si ejecuta la canalización en una rama dev, extenderá la plantilla especificada por el template.yml archivo en la dev rama del templates repositorio.

También puede elegir, en tiempo de cola de compilación, qué rama del repositorio de plantillas se va a usar; para ello, escriba el siguiente código YAML.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Ahora, puede hacer que la canalización en la rama main extienda una plantilla desde una rama dev en una ejecución y ampliar una plantilla desde una rama main en otra ejecución, sin cambiar el código de la canalización.

Al especificar una expresión de plantilla para la ref propiedad de un recurso de repositorio, puede usar y las parameters variables predefinidas del sistema, pero no puede usar variables definidas por la interfaz de usuario de YAML o Pipelines.

Expresiones de plantilla en definición de recursos de contenedor

Se ha agregado compatibilidad con expresiones de plantilla al definir las endpointpropiedades , volumes, portsy options de un container recurso en una canalización YAML. Esta fue una característica muy solicitada por nuestra Comunidad de desarrolladores.

Ahora, puede escribir canalizaciones YAML como las siguientes.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Puede usar parameters. y variables. en las expresiones de plantilla. En el caso de las variables, solo puede usar las definidas en el archivo YAML, pero no las definidas en la interfaz de usuario de canalizaciones. Si vuelve a definir la variable, por ejemplo, mediante comandos de registro del agente, no tendrá ningún efecto.

Auditar eventos para cambios en aprobaciones

Las aprobaciones permiten controlar cuándo se debe ejecutar una fase. Estas comprobaciones se usan normalmente para controlar las implementaciones en entornos de producción. La auditoría le permite cumplir los requisitos de cumplimiento y supervisar la seguridad de su organización de Azure DevOps.

Cuando se pide a un usuario que apruebe una canalización para implementar en una fase determinada, ese usuario puede optar por reasignar la aprobación a otra persona.

Auditar eventos para cambios en aprobaciones

Hasta ahora, estas acciones no se registraron en los registros de auditoría. Este problema se ha corregido ahora.

Los registros de auditoría contendrán una entrada similar a la siguiente.

[
    {
        "Id": "2517368925862632546;00000264-0000-8888-8000-000000000000;839ad1ba-f72b-4258-bc3f-88be7a4553b5",
        "CorrelationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "ActivityId": "a298a06c-965f-4e60-9643-2593f2066e37",
        "ActorCUID": "fe950802-bf07-755b-826d-e8dcc066252c",
        "ActorUserId": "fe950802-bf07-755b-826d-e8dcc066252c",
        "ActorUPN": "silviu@fabrikam.app",
        "AuthenticationMechanism": "AAD_Cookie",
        "Timestamp": "2022-10-10T11:26:53.7367453Z",
        "ScopeType": "Organization",
        "ScopeDisplayName": "Fabrikam (Organization)",
        "ScopeId": "547a7316-cdf4-40d2-af16-3215f97d053e",
        "ProjectId": "4bf16944-3595-421f-9947-79d9eb190284",
        "ProjectName": "FabrikamFiber",
        "IpAddress": "127.0.0.1",
        "UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.37",
        "ActionId": "ApproverReassigned",
        "Data": {
            "ApprovalId": "dae6e7c9-2a10-4cd8-b63a-579a6e7ba78d",
            "OldApproverUserId": "692b6e2a-dd61-4872-866a-85498da390fc",
            "OldApproverDisplayName": "[FabrikamFiber]\\Build Administrators",
            "NewApproverUserId": "fe95080b-bf07-655b-226d-e8dcc066252c",
            "NewApproverDisplayName": "Jack Fabrikam",
            "Comment": "All admins are OOO"
        },
        "Details": "Reassigned approver of Approval dae6e7c9-9a10-4cd8-b63a-579a6e7ba78d in Project \"FabrikamFiber\" from \"[FabrikamFiber]\\Build Administrators\" to \"Jack Fabrikam\" with comment \"All admins are OOO\".",
        "Area": "Checks",
        "Category": "Modify",
        "CategoryDisplayName": "Modify",
        "ActorDisplayName": "Silviu"
    }
]

Además, se mostrará en la interfaz de usuario de auditoría.

Entrada de registro en la interfaz de usuario de auditoría

La biblioteca de tareas expone el modelo de hospedaje del agente

Los autores de tareas que desean determinar si un agente se ejecuta en grupos hospedados por Microsoft o no ahora puede usar la función getAgentMode() Biblioteca de tareas para determinar el modelo de hospedaje. Esto es beneficioso en escenarios en los que una tarea quiere influir en el comportamiento en función de tener acceso a la red de un cliente o no. Una tarea puede intentar llegar a un servicio de Azure a través de un punto de conexión privado si se ejecuta desde un agente autohospedado o agentes de conjunto de escalado que residen en la red de un cliente. Consulte la referencia de tareas.

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,

Vijay Machiraju