Partager via

Prise en charge de la table de sous-pages dans wiki

  • Article

Vous pouvez maintenant ajouter un tableau de sous-pages à vos pages wiki afin de voir le contenu et les liens. Dans Tableaux, vous pouvez maintenant ajouter des couleurs au couloir de bain et empêcher la modification des champs personnalisés. Nous poursuivons également nos investissements dans la sécurité et avons ajouté une nouvelle portée PAT pour la gestion des autorisations de pipeline, des approbations et des vérifications.

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

Azure Boards

Azure Pipelines

Wiki

Azure Boards

Empêcher la modification des champs de listes de choix partageables

Les champs personnalisés sont partagés entre les processus. Cela peut créer un problème pour les champs de liste de sélection, car nous permettons aux administrateurs de processus d’ajouter ou de supprimer des valeurs du champ. Dans ce cas, les modifications affectent ce champ sur chaque processus qui l’utilise.

Pour résoudre ce problème, nous avons ajouté la possibilité pour l’administrateur de collection de « verrouiller » un champ en cours de modification. Lorsque le champ de liste de sélection est verrouillé, l’administrateur de processus local ne peut pas modifier les valeurs de cette liste de sélection. Ils peuvent uniquement ajouter ou supprimer le champ du processus.

Gif pour la modification de démonstration des champs de liste de choix partageables.

Couleurs du couloir de bain

Dans votre tableau Kanban, les couloirs vous aident à visualiser les status de travail qui prennent en charge différentes classes de niveau de service. Maintenant, vous pouvez ajouter de la couleur aux couloirs pour les rendre plus faciles à identifier dans votre tableau.

Gif à la démonstration ajout de couleur aux couloirs.

Notes

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

Azure Pipelines

Nouvelle étendue PAT pour la gestion des autorisations de pipeline, des approbations et des vérifications

Pour limiter les dommages causés par la fuite d’un jeton PAT, nous avons ajouté une nouvelle étendue PAT, nommée Pipeline Resources. Vous pouvez utiliser cette étendue PAT lors de la gestion de l’autorisation de pipeline à l’aide d’une ressource protégée, telle qu’une connexion de service, ou pour gérer les approbations et les vérifications de cette ressource.

Api REST pipelines Mises à jour

Les appels d’API REST suivants prennent en charge la nouvelle étendue PAT comme suit :

Améliorations apportées aux autorisations de pipeline

Nous avons amélioré l’expérience de gestion des autorisations de pipeline pour que le système d’autorisations se souvienne si un pipeline avait déjà utilisé une ressource protégée, telle qu’une connexion de service.

Dans le passé, si vous avez coché « Accorder l’autorisation d’accès à tous les pipelines » lorsque vous avez créé une ressource protégée, mais que vous avez ensuite restreint l’accès à la ressource, votre pipeline avait besoin d’une nouvelle autorisation pour utiliser la ressource. Ce comportement n’était pas cohérent avec l’ouverture et la fermeture ultérieures de l’accès à la ressource, où une nouvelle autorisation n’était pas requise. Ce problème est maintenant résolu.

Variables en tant qu’entrées dans les vérifications

Les approbations et les vérifications sont un mécanisme de sécurité d’exécution qui permet aux propriétaires de ressources de contrôler les exécutions de pipeline qui peuvent utiliser leur ressource.

Deux vérifications courantes sont Invoke Azure Function et Invoke REST API. Dans le passé, lors de leur configuration, on ne pouvait utiliser que des variables système prédéfinies ou des groupes de variables.

Dans ce sprint, nous avons ajouté la prise en charge des variables définies par le pipeline. Cela fonctionne lors de la spécification des Function keyparamètres , Headers, Bodyet Query pour de telles vérifications.

Supposons que vous disposez du pipeline YAML suivant. Notez que nous définissons les variables FunctionKey, MyHeader, MyBodyet MyQueryune variable définie par le runtime nomméeRetryCount.

variables:
  FunctionKey: <<redacted>>
  MyHeader: "FabrikamHeader"
  MyQuery: "FabrikamQuery"
  MyBody: "FabrikamBody"

stages: 
- stage: Build
  jobs:
  - job: SetRC
    steps:
    - script: echo "##vso[task.setvariable variable=RetryCount;isOutput=true]3"
      name: RCValue
- stage: Deploy
  jobs:
  - deployment: 
    environment: Production
    strategy:
      runOnce:
        deploy:
          steps:
          - script: ./deploy.sh

Vous pouvez configurer une case activée d’appel de fonction Azure sur l’environnement de production et référencer $(FunctionKey), $(MyHeader), $(MyBody), $(MyQuery)et $(Build.SetRC.RCValue.RetryCount), comme dans la capture d’écran suivante.

Appeler une fonction Azure

La syntaxe de l’utilisation de variables définies par le runtime est StageId.JobId.StepOrTaskName.Variable.

En savoir plus sur la méthode recommandée pour utiliser les vérifications de l’API Invoke Azure Function &REST.

Possibilité de désactiver le masquage pour les secrets courts

Azure Pipelines masque les secrets dans les journaux. Les secrets peuvent être des variables marquées comme secrètes, des variables de groupes de variables liés à Azure Key Vault ou des éléments d’une connexion de service marqués comme secret par le fournisseur de connexion de service.

Toutes les occurrences de valeur de secret sont masquées. Le masquage de secrets courts, par exemple « »,1 « », «Dev » permet de deviner facilement leurs valeurs, par exemple dans une date : «Jan 3, 202***2 »
Il est maintenant clair que '3' est un secret. Dans ce cas, vous préférerez peut-être ne pas masquer complètement le secret. S’il n’est pas possible de marquer la valeur comme secret (par exemple, la valeur est extraite de Key Vault), vous pouvez définir le AZP_IGNORE_SECRETS_SHORTER_THAN bouton sur une valeur allant jusqu’à 4.

Script pour valider automatiquement la version de l’agent de pipeline

Nous avons actuellement deux versions de l’agent pipeline : v2 utilise .NET 3.1 Core et v3 utilise .NET 6. Nous déployons lentement l’agent v3 sur les systèmes d’exploitation pris en charge, après quoi nous allons mettre hors service l’agent v2. Pour plus d’informations, consultez le billet de blog mise à niveau de l’agent .NET pour Azure Pipelines.

Nous avons créé un script pour vous aider à vérifier si vos agents auto-hébergés pourront effectuer une mise à niveau. Ce script traite tous les pools de votre organization et identifie les agents v2 sur les systèmes d’exploitation qui ne sont pas pris en charge par l’agent v3, par exemple CentOS 6, Fedora versions antérieures à 31, macOS 10.14, RHEL 6.

Notes

Les builds récentes de l’agent v2 ne tenteront pas de mettre à niveau automatiquement l’agent v3 sur un système d’exploitation connu pour ne pas être compatible avec celui-ci.

Icône de vue d’ensemble de l’exécution du pipeline status

Dans ce sprint, il est plus facile de connaître la status globale d’une exécution de pipeline.

Pour les pipelines YAML qui ont de nombreuses étapes, il était difficile de savoir la status d’une exécution de pipeline, autrement dit, s’il est toujours en cours d’exécution ou s’il s’est terminé. Et si elle s’est terminée, quel est l’état global : réussite, échec ou annulation. Nous avons résolu ce problème en ajoutant une exécution status icône de vue d’ensemble.

Icône de vue d’ensemble de l’exécution du pipeline status

Wiki

Prise en charge de la table des sous-pages

Vous pouvez maintenant ajouter une table de contenu pour les sous-pages à vos pages wiki. Ce tableau contient des liens vers toutes les sous-pages situées sous la page où la table des sous-pages est affichée.

Vous pouvez ajouter la table des sous-pages en insérant manuellement la balise spéciale [[_TOSP_]] ou à partir d’autres options , comme illustré dans l’image animée ci-dessous. Seule la première balise [[_TOSP_]] est utilisée pour créer la table des sous-pages.

Cette fonctionnalité a été hiérarchisée en fonction des tickets de suggestion de la communauté suivants :

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

Faire une suggestion

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

Merci,

Rajesh Ramamurthy