Basculer entre l’éditeur HTML et Markdown dans les commentaires d’Azure Boards en préversion privée

Avec cette mise à jour, vous pouvez désormais basculer entre l’éditeur HTML et Markdown dans les commentaires Azure Boards.

Consultez les notes de publication pour en savoir plus sur l’inscription dans la préversion privée pour cette fonctionnalité.

Azure Boards

• Basculer entre HTML ou Markdown sur les commentaires

Azure Pipelines

• Amélioration de la validation YAML
• Vérifie la scalabilité de la phase 3

Azure Boards

Basculer entre HTML ou Markdown sur les commentaires

Il y a quelques mois, nous avons introduit une préversion privée pour activer Markdown pour les commentaires sur les éléments de travail, visant à remplacer entièrement l’éditeur HTML existant. Nous avons reçu vos commentaires, exprimant une préférence pour l’éditeur HTML et nous avons ajusté notre approche. Vous avez maintenant la possibilité de basculer entre l’éditeur HTML et Markdown au niveau du commentaire.

Voici ce que vous devez attendre :

• L’éditeur par défaut est collant à partir du dernier commentaire que vous avez créé.
• Vous pouvez convertir des commentaires HTML existants en Markdown.
• Une fois qu’un commentaire Markdown est créé ou mis à jour, il ne peut pas être converti en HTML.

Cette mise à jour est implémentée dans toutes les organisations préinscrites et celles avec le hub New Boards activé par défaut. En outre, nous étendons la période de préversion pendant quelques semaines supplémentaires pour recueillir plus de commentaires. Si vous souhaitez vous inscrire à la préversion privée, n’hésitez pas à contacter directement par e-mail et incluez le nom de votre organisation (dev.azure.com/{organisation}).

Conseil

Envisagez d’inscrire dans la préversion uniquement si votre organisation est entièrement engagée à utiliser le New Boards Hub pour tous les utilisateurs. L’expérience avec les commentaires Markdown dans les old boards peut ne pas être optimale.

Azure Pipelines

Amélioration de la validation YAML

Pour vérifier que votre syntaxe YAML est correcte, vous pouvez utiliser la fonctionnalité Valider de l’éditeur web Azure Pipelines. Par conséquent, il est important que cette fonctionnalité intercepte autant de problèmes YAML que possible.

Avec ce sprint, la validation YAML est plus approfondie en ce qui concerne les expressions.

Lorsque vous écrivez des pipelines YAML, vous pouvez utiliser des fonctions pour définir des valeurs de variable.

Imaginez que vous définissez les variables suivantes :

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

La Patch variable est définie à l’aide de la counter fonction et des deux autres variables. Dans le code YAML ci-dessus, le mot format est malté. Auparavant, cette erreur n’a pas été détectée. À présent, la fonctionnalité Valider détecte cette fonctionnalité et affiche un message d’erreur.

Azure Pipelines détecte les définitions de variables incorrectes au niveau du pipeline/ de l’étape/du travail.

Dans les pipelines YAML, vous pouvez ignorer l’exécution de l’étape à l’aide de conditions. Les fautes de frappe peuvent également apparaître ici, comme dans l’exemple suivant.

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

La NuGetCommand tâche s’exécute uniquement si la valeur de la Patch variable est 0. Là encore, il existe une faute de frappe dans la condition, et la fonctionnalité Valider l’affiche.

Azure Pipelines détecte les conditions YAML incorrectes définies au niveau du pipeline/ de l’étape/du travail.

Vérifie la scalabilité de la phase 3

Comme mentionné dans notre Mises à jour pour Approbations et le billet de blog Vérifications, nous travaillons à améliorer l’évolutivité de notre Approbations & Checks.

Avancer dans la phase 3, nous allons effectuer des brunouts hebdomadaires et longs, pendant lesquels toutes les exécutions de pipeline qui utilisent des case activée non conformes échoueront.

Les dates de brunout planifiées sont les suivantes :

• 9 janvier 2024, 08 :00 UTC au 10 janvier 2024, 08 :00 UTC
• 16 janvier 2024, 08 :00 UTC au 17 janvier 2024, 08 :00 UTC
• 23 janvier 2024, 08 :00 UTC au 24 janvier 2024, 08 :00 UTC
• 30 janvier 2024, 08 :00 UTC au 31 janvier 2024, 08 :00 UTC

É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,

Dan Hellem