Prise en charge des agents personnalisés de GitHub Copilot dans Azure Boards

Azure Boards prend désormais en charge la sélection d'agents personnalisés GitHub Copilot lors de la création d’un pull request à partir d’un élément de travail. Les agents personnalisés créés au niveau du référentiel ou de l’organisation dans GitHub apparaissent automatiquement dans Azure DevOps, et l'agent que vous avez sélectionné générera les modifications de code et créera la pull request dans le référentiel choisi.

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

GitHub Advanced Security for Azure DevOps

• Application des autorisations dans la vue d’ensemble de la sécurité
• Générer l’accès aux identités restreint pour les API Advanced Security (rétabli temporairement)
• Détection d’analyse obsolète dans la couverture de la sécurité

Azure Boards

• L'intégration de Azure Boards à GitHub Copilot prend désormais en charge les agents personnalisés
• limite maximale augmentée pour les dépôts GitHub connectés

Azure Repos

• API de configuration de stratégie Git améliorée

Azure Pipelines

• Débogage amélioré de l’exécution du pipeline

GitHub Advanced Security for Azure DevOps

Application des autorisations dans la vue d’ensemble de la sécurité

La vue d’ensemble de la sécurité applique désormais l’autorisation Advanced Security : Lire les alertes sur toutes les vues (Risque et couverture). Les dépôts où l’utilisateur actuel ne dispose pas de cette autorisation ne sont plus visibles dans les résultats de la vue d’ensemble de la sécurité. Cette modification garantit que la vue d’ensemble de la sécurité respecte les mêmes contrôles d’accès que l’expérience des alertes au niveau du référentiel, ce qui empêche toute visibilité non autorisée sur les référentiels ayant des résultats actifs.

Générer l’accès aux identités restreint pour les API Advanced Security (rétabli temporairement)

Cette modification a été annulée temporairement. Pour plus d'informations, consultez la restauration de l'accès restreint aux identités de build pour les API de sécurité avancée.

Les API REST Advanced Security n’acceptent plus les identités de service de génération (telles que Project Collection Build Service) en tant qu’appelants. Cette modification empêche l’automatisation basée sur le pipeline d’accéder ou de modifier des données d’alerte de sécurité à l’aide de comptes de service de build, ce qui réduit le risque de modifications d’état d’alerte involontaires pendant les exécutions CI/CD. Si vous disposez d’une automatisation qui interagit avec les API Advanced Security à l’aide d’une identité de build, mettez à jour ces flux de travail pour utiliser un utilisateur ou un principal de service nommé avec les autorisations Advanced Security appropriées.

Détection d’analyse obsolète dans la couverture de la sécurité

Le volet de couverture de la vue d’ensemble de la sécurité identifie désormais les outils avec des analyses datant de plus de 90 jours. Les outils qui n’ont pas produit de résultats depuis plus de 90 jours affichent un indicateur obsolète, aidant les équipes de sécurité à repérer rapidement les référentiels où l’analyse peut avoir cessé d’exécuter ou où les configurations de pipeline ont besoin d’attention. Cette visibilité facilite le maintien d’une couverture complète de l’analyse dans votre organisation et de détecter la dérive de configuration avant qu'elle ne crée des zones d'ombre.

Azure Boards

Azure Boards intégration de GitHub Copilot prend en charge désormais les agents personnalisés

L’intégration Azure Boards à GitHub Copilot prend désormais en charge la sélection d’agents personnalisés. Si vous n’êtes pas déjà familiarisé avec les agents personnalisés, vous pouvez en savoir plus sur ces derniers dans la documentation sur la création d’agents personnalisés.

Une fois que vous avez créé un agent personnalisé au niveau du référentiel ou de l’organisation, il sera automatiquement disponible dans Azure DevOps. Lorsque vous créez une pull request à partir d’un élément de travail, un nouveau contrôle de sélection d'agent s’affiche à côté de la liste des référentiels.

Après avoir sélectionné un agent personnalisé et cliqué sur Créer, cet agent sera utilisé pour appliquer les modifications du code et créer le pull request dans le référentiel sélectionné.

Augmentation de la limite maximale pour les référentiels de GitHub connectés

Nous avons augmenté la limite par connexion lors de la liaison de référentiels GitHub à un projet Azure DevOps. La nouvelle limite maximale dans l’expérience web est désormais de 2 000, correspondant à la limite déjà disponible via l’API REST Update.

Azure Repos

API de configuration de stratégie Git améliorée

Les API de configuration de stratégie sont améliorées pour faciliter et améliorer l’efficacité de la récupération de toutes les stratégies qui s’appliquent à un référentiel spécifique. Vous pouvez désormais interroger les stratégies définies au niveau du référentiel et les stratégies appliquées à toutes les branches ou ReFS au sein de ce référentiel, sans avoir à analyser l’intégralité du projet. Cette amélioration réduit les appels d’API inutiles et améliore les performances des services qui gèrent les stratégies à grande échelle. Le comportement de stratégie existant reste inchangé.

Configurations de stratégies - Obtenir - API REST (Azure DevOps Git)

Azure Pipelines

Débogage amélioré de l’exécution du pipeline

Dans ce sprint, nous améliorons votre capacité à déboguer des exécutions de pipeline.

Il se peut que vous deviez annuler votre exécution, mais que la tâche ou l’étape continue de s’exécuter, ce qui peut causer de la confusion. Nous avons ajouté des messages d’avertissement pour vous indiquer quand et pourquoi c’est le cas.

Imaginez que vous disposez du YAML suivant :

stages:
- stage: WUS1
  jobs:
  - job: DeployWUS1
    condition: eq(variables['Build.SourceBranchName'], 'main')
    steps:
    - task: CmdLine@2
      inputs:
        script: echo "Deploying $(System.StageName)"
    - task: CmdLine@2
      inputs:
        script: sleep 60
- stage: WUS2
  condition: eq(variables['Build.SourceBranchName'], 'main')
  jobs:
  - job: DeployWUS2
    steps:
    - task: CmdLine@2
      inputs:
        script: echo "Deploying $(System.StageName)"

Imaginez maintenant que vous annulez l’exécution lors de l’exécution du travail DeployWUS1. Le travail continuera à s’exécuter, ainsi que l'étape WUS2. Azure Pipelines vous indique pourquoi la tâche et la phase continuent de s’exécuter.

Une autre amélioration que nous apportons vous permet de savoir pourquoi une étape est ignorée.

Imaginez que vous exécutez le même YAML à partir d’une autre branche, par exemple, release_123et que vous choisissez d’exécuter uniquement la phase WUS2. Auparavant, les étapes WUS1 et WUS2 avaient le même statut, Skipped, mais il n’était pas clair pourquoi chacune des étapes était ignorée. Maintenant, vous savez si l’étape a été ignorée, car vous l’avez désélectionnée au moment de l’exécution de la file d’attente ou en raison de ses conditions d’exécution.

Étapes suivantes

Comment fournir des commentaires

Nous aimerions entendre ce que vous pensez de ces fonctionnalités. Utilisez le menu d’aide pour signaler un problème ou fournir une suggestion.

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