Prise en charge des expressions de modèle dans les définitions de ressources de référentiel et de conteneur

Avec cette mise à jour, nous avons inclus la prise en charge des expressions de modèle dans les définitions de ressources de référentiel et de conteneur. Vous pouvez maintenant utiliser des expressions de modèle lors de la définition de la ref propriété d’une repository ressource dans un pipeline YAML pour choisir la branche d’une ressource de référentiel. En outre, nous avons ajouté la prise en charge des expressions de modèle lors de la définition des propriétés et options portsdes endpointvolumespropriétés d’une container ressource dans un pipeline YAML.

Pour plus d’informations, consultez les notes de publication.

Azure Boards

• Modifier les types de liens d’élément de travail
• Créer un point de terminaison REST de requête temporaire
• API de suppression batch (préversion privée)
• macro @CurrentIteration dans les plans de remise

Azure Pipelines

• Expressions de modèle dans la définition de ressource du référentiel
• Expressions de modèle dans la définition de ressource de conteneur
• Événements d’audit pour les modifications apportées aux approbations
• La bibliothèque de tâches expose le modèle d’hébergement de l’agent

Azure Boards

Modifier les types de liens d’élément de travail

Auparavant, la modification d’un lien d’élément de travail nécessite au moins trois étapes. Par exemple, pour modifier un lien parent vers un lien associé, vous devez copier l’ID d’élément de travail, supprimer le lien parent, ajouter un nouveau lien existant de type associé, puis coller l’ID copié et enregistrer. C’est un processus fastidieux.

Nous avons résolu le problème en vous permettant de modifier et de modifier directement le type de lien. Vous pouvez rapidement modifier le type de lien en une seule étape.

Remarque

Cette fonctionnalité sera disponible uniquement avec la préversion de New Boards Hubs.

Créer un point de terminaison REST de requête temporaire

Nous avons vu plusieurs instances d’auteurs d’extensions qui tentent d’exécuter des requêtes non enregistrées en passant l’instruction WIQL (Work Item Query Language) via la chaîne de requête. Cela fonctionne correctement, sauf si vous avez une instruction WIQL volumineuse qui atteint les limites du navigateur sur la longueur de la chaîne de requête. Pour résoudre ce problème, nous avons créé un nouveau point de terminaison REST pour permettre aux auteurs d’outils de générer une requête temporaire. L’utilisation de l’ID de la réponse pour passer via querystring élimine ce problème.

Pour en savoir plus, consultez la page de documentation de l’API REST des requêtes temporaires.

API de suppression batch (préversion privée)

Actuellement, la seule façon de supprimer des éléments de travail de la corbeille utilise cette API REST pour en supprimer une à la fois. Il peut s’agir d’un processus lent et est soumis à une limitation de débit lorsque vous essayez de faire n’importe quel type de nettoyage de masse. En réponse, nous avons ajouté un nouveau point de terminaison d’API REST pour supprimer et/ou détruire des éléments de travail par lots.

Si vous souhaitez participer à une préversion privée de ce nouveau point de terminaison, envoyez-nous un e-mail directement.

@CurrentIteration macro dans les plans de livraison

Avec cette mise à jour, nous avons ajouté la prise en charge de la macro pour les @CurrentIteration styles dans les plans de livraison. Cette macro vous permet d’obtenir l’itération actuelle à partir du contexte d’équipe de chaque ligne de votre plan.

Azure Pipelines

Expressions de modèle dans la définition de ressource du référentiel

Nous avons ajouté la prise en charge des expressions de modèle lors de la définition de la ref propriété d’une repository ressource dans un pipeline YAML. Il s’agissait d’une fonctionnalité hautement demandée par notre Communauté des développeurs.

Il existe des cas d’usage lorsque vous souhaitez que votre pipeline examine différentes branches de la même ressource de référentiel.

Par exemple, supposons que vous disposez d’un pipeline qui génère son propre référentiel et, pour cela, il doit extraire une bibliothèque à partir d’un référentiel de ressources. En outre, supposons que votre pipeline vérifie la même branche de bibliothèque que celle utilisée par lui-même. Par exemple, si votre pipeline s’exécute sur la main branche, il doit extraire la main branche du référentiel de bibliothèque. Si les pipelines s’exécutent sur la dev branche, il doit extraire la dev branche de bibliothèque.

Jusqu’à aujourd’hui, vous deviez spécifier explicitement la branche à extraire et modifier le code du pipeline chaque fois que la branche change.

À présent, vous pouvez utiliser des expressions de modèle pour choisir la branche d’une ressource de référentiel. Consultez l’exemple suivant de code YAML à utiliser pour les branches non principales de votre pipeline :

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

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

Lorsque vous exécutez le pipeline, vous pouvez spécifier la branche à extraire pour le library référentiel.

Spécifier la version d’un modèle à étendre au moment de la file d’attente de build

Les modèles représentent un excellent moyen de réduire la duplication de code et d’améliorer la sécurité de vos pipelines.

Un cas d’usage populaire consiste à héberger des modèles dans leur propre dépôt. Cela réduit le couplage entre un modèle et les pipelines qui l’étendent et facilite l’évolution du modèle et des pipelines indépendamment.

Prenons l’exemple suivant, dans lequel un modèle est utilisé pour surveiller l’exécution d’une liste d’étapes. Le code du modèle se trouve dans le Templates référentiel.

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

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

Supposons que vous disposez d’un pipeline YAML qui étend ce modèle, situé dans le référentiel FabrikamFiber. Jusqu’à aujourd’hui, il n’était pas possible de spécifier dynamiquement la ref propriété de la templates ressource de référentiel lors de l’utilisation du référentiel comme source de modèle. Cela signifie que vous deviez modifier le code du pipeline si vous vouliez que votre pipeline : étendre un modèle à partir d’une autre branche étend un modèle du même nom de branche que votre pipeline, quelle que soit la branche que vous avez exécutée dans votre pipeline

Avec l’introduction d’expressions de modèle dans la définition de ressource du référentiel, vous pouvez écrire votre pipeline comme suit :

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

Ainsi, votre pipeline étend le modèle dans la même branche que la branche sur laquelle le pipeline s’exécute. Vous pouvez donc vous assurer que les branches de votre pipeline et du modèle correspondent toujours. Autrement dit, si vous exécutez votre pipeline sur une branche dev, il étend le modèle spécifié par le template.yml fichier dans la dev branche du templates référentiel.

Vous pouvez également choisir, au moment de la génération, la branche de référentiel de modèles à utiliser, en écrivant le code YAML suivant.

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

À présent, vous pouvez avoir votre pipeline sur la branche main étendre un modèle à partir d’une branche dev dans une exécution et étendre un modèle à partir d’une branche main dans une autre exécution, sans modifier le code de votre pipeline.

Lorsque vous spécifiez une expression de modèle pour la ref propriété d’une ressource de référentiel, vous pouvez utiliser et système parameters des variables prédéfinies, mais vous ne pouvez pas utiliser des variables DÉFINIES par l’interface utilisateur YAML ou Pipelines.

Expressions de modèle dans la définition de ressource de conteneur

Nous avons ajouté la prise en charge des expressions de modèle lors de la définition des propriétés et options portsdes endpointvolumespropriétés d’une container ressource dans un pipeline YAML. Il s’agissait d’une fonctionnalité hautement demandée par notre Communauté des développeurs.

À présent, vous pouvez écrire des pipelines YAML comme suit.

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'

Vous pouvez utiliser parameters. et variables. dans vos expressions de modèle. Pour les variables, vous ne pouvez utiliser que celles définies dans le fichier YAML, mais pas celles définies dans l’interface utilisateur de Pipelines. Si vous redéfinissez la variable, par exemple, à l’aide de commandes de journal d’agent, elle n’aura aucun effet.

Événements d’audit pour les modifications apportées aux approbations

Les approbations vous permettent de contrôler quand une phase doit s’exécuter. Cette vérification est couramment utilisée pour contrôler les déploiements dans des environnements de production. L’audit vous permet de répondre aux exigences de conformité et de surveiller la sécurité de votre organisation Azure DevOps.

Lorsqu’un utilisateur est invité à approuver un pipeline à déployer à une étape particulière, cet utilisateur peut choisir de réaffecter l’approbation à une autre personne.

Jusqu’à présent, ces actions n’ont pas été enregistrées dans les journaux d’audit. Ce problème est résolu maintenant.

Les journaux d’audit contiennent une entrée similaire à ce qui suit.

[
    {
        "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"
    }
]

En outre, il s’affiche dans l’interface utilisateur d’audit.

La bibliothèque de tâches expose le modèle d’hébergement de l’agent

Les auteurs de tâches qui souhaitent déterminer si un agent s’exécute dans des pools hébergés par Microsoft ou non peuvent désormais utiliser la fonction getAgentMode() Bibliothèque de tâches pour déterminer le modèle d’hébergement. Cela est bénéfique dans les scénarios où une tâche souhaite influencer le comportement en fonction de l’accès au réseau d’un client ou non. Une tâche peut essayer d’atteindre un service Azure sur un point de terminaison privé s’il est exécuté à partir d’un agent auto-hébergé ou d’agents de groupe identique qui résident dans le réseau d’un client. Consultez la référence de tâche.

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Vijay Machiraju