Lire en anglais

Partager via

Résolution de plusieurs demandes provenant du Developer Community

  • Article

En réponse à vos commentaires, nous avons hiérarchisé plusieurs fonctionnalités que vous avez demandées dans le Developer Community. Dans Pipelines, nous avons ajouté la prise en charge de la fonction de fractionnement de chaîne dans l’expression YAML. En outre, nous vous permetons maintenant de désactiver l’affichage du dernier message de validation pour une exécution de pipeline. Dans les plans de livraison, nous avons augmenté la limite d’équipe de 15 à 20.

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

Azure Boards

Azure Pipelines

Azure Boards

Augmenter la limite d’équipe des plans de livraison de 15 à 20

Les plans de livraison vous permettent d’afficher plusieurs backlogs et plusieurs équipes dans votre organization. Auparavant, vous pouviez afficher 15 backlogs d’équipe, y compris un mélange de backlogs et d’équipes de différents projets. Dans ce sprint, nous avons augmenté la limite maximale de 15 à 20.

Nous avons résolu un bogue dans l’API Get des liens d’élément de travail de création de rapports pour renvoyer la valeur remoteUrl correcte pour les System.LinkTypes.Remote.Related types de liens. Avant ce correctif, nous renvoyions le nom de organization incorrect et un ID de projet manquant.

Nouveaux correctifs de bogues boards Hub

Dans ce sprint, nous avons résolu plusieurs bogues pour new boards hub. Vous pouvez voir la liste des correctifs de bogues dans le billet de blog New Boards Hub, Sprint 209 Update.

Azure Pipelines

Désactiver l’affichage du dernier message de validation pour une exécution de pipeline

Auparavant, l’interface utilisateur pipelines était utilisée pour afficher le dernier message de validation lors de l’affichage de l’exécution d’un pipeline.

Exemple de message de dernière validation

Ce message peut prêter à confusion, par exemple, lorsque le code de votre pipeline YAML réside dans un dépôt différent de celui qui contient le code qu’il génère. Nous avons entendu vos commentaires du Developer Community nous demandant un moyen d’activer/désactiver l’ajout du message de validation le plus récent au titre de chaque exécution de pipeline.

Avec cette mise à jour, nous avons ajouté une nouvelle propriété YAML, nommée appendCommitMessageToRunName, qui vous permet de le faire exactement. Par défaut, la propriété est définie sur true. Lorsque vous le définissez sur false, l’exécution du pipeline affiche uniquement le BuildNumber.

Exemple d’exécution de pipeline avec le numéro de build

Exemple d’exécution de pipeline avec le dernier message de validation

Ressources consommées et paramètres de modèle dans Pipelines Exécute l’API Rest

L’API REST Pipelines Exécute les pipelines étendues retourne désormais d’autres types d’artefacts utilisés par une exécution de pipeline et les paramètres utilisés pour déclencher cette exécution. Nous avons amélioré l’API pour retourner les container ressources et et pipeline les paramètres de modèle utilisés dans une exécution de pipeline. Vous pouvez maintenant, par exemple, écrire des vérifications de conformité qui évaluent les dépôts, conteneurs et autres exécutions de pipeline utilisées par un pipeline.

Voici un exemple du nouveau corps de réponse.

JSON 
"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Ajout de la prise en charge de la fonction de fractionnement de chaîne dans les expressions de modèle YAML

Les pipelines YAML vous fournissent des moyens pratiques de réduire la duplication de code, par exemple le bouclage de each la valeur d’une liste ou d’une propriété d’un objet.

Parfois, l’ensemble d’éléments à itérer à travers est représenté sous la forme d’une chaîne. Par exemple, lorsque la liste des environnements dans ant est définie par la chaîne integration1, integration2.

Lorsque nous avons écouté vos commentaires du Developer Community, nous avons entendu dire que vous souhaitiez une fonction de chaîne split dans les expressions de modèle YAML.

Maintenant, vous pouvez split une chaîne et itérer sur each ses sous-chaînes.

YAML 
variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Ne pas synchroniser les balises lors de l’extraction d’un dépôt Git

La tâche de validation utilise l’option --tags pour extraire le contenu d’un dépôt Git. Le serveur récupère alors toutes les étiquettes ainsi que de tous les objets désignés par ces étiquettes. Cela augmente le temps d’exécution de la tâche dans un pipeline, en particulier si vous disposez d’un dépôt volumineux avec un certain nombre de balises. En outre, la tâche d’extraction synchronise les balises même lorsque vous activez l’option d’extraction superficielle, ce qui peut aller à l’échec de son objectif. Pour réduire la quantité de données extraites ou extraites d’un dépôt Git, nous avons maintenant ajouté une nouvelle option à la tâche pour contrôler le comportement de synchronisation des balises. Cette option est disponible à la fois dans les pipelines classiques et YAML.

Ce comportement peut être contrôlé à partir du fichier YAML ou de l’interface utilisateur.

Pour désactiver la synchronisation des balises via le fichier YAML, ajoutez à l’étape fetchTags: false de validation. Lorsque l’option fetchTags n’est pas spécifiée, elle est identique à celle fetchTags: true utilisée.

YAML 
steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Si vous souhaitez modifier le comportement des pipelines YAML existants, il peut être plus pratique de définir cette option dans l’interface utilisateur au lieu de mettre à jour le fichier YAML. Pour accéder à l’interface utilisateur, ouvrez l’éditeur YAML pour le pipeline, sélectionnez Déclencheurs, puis Traiter, puis l’étape Extraction.

Si vous spécifiez ce paramètre à la fois dans le fichier YAML et dans l’interface utilisateur, la valeur spécifiée dans le fichier YAML est prioritaire.

Pour tous les pipelines que vous créez (YAML ou Classic), les balises sont toujours synchronisées par défaut. Cette option ne modifie pas le comportement des pipelines existants. Les balises seront toujours synchronisées dans ces pipelines, sauf si vous modifiez explicitement l’option comme décrit ci-dessus.

Planification d’abandon mise à jour pour les images Ubuntu 18.04

Azure Pipelines déprécie l’image Ubuntu 18.04 (ubuntu-18.04) sur nos pools hébergés. Cette image sera retirée le 1er décembre. Vous pouvez commencer à voir des temps de file d’attente plus longs.

Pour vous aider à mieux identifier les pipelines qui utilisent l’image ubuntu-18.04, nous prévoyons des brownouts. Les travaux échouent pendant une période d’abandon.

  • Les messages d’avertissement s’affichent sur les exécutions de pipeline à l’aide de l’image ubuntu-18.04
  • Un script est disponible pour vous aider à trouver des pipelines à l’aide d’images déconseillées, y compris ubuntu-18.04
  • Nous programmons de courts « brownouts ». Toutes les exécutions ubuntu-18.04 échouent pendant la période d’abandon. Par conséquent, il est recommandé de migrer vos pipelines avant les brownouts.

Planification brownout (mise à jour)

  • 3 octobre, 12:00 UTC - 3 octobre, 14:00 UTC
  • 18 octobre, 14:00 UTC - Octobre 18, 16:00 UTC
  • 15 novembre, 18:00 UTC - Novembre 15, 20:00 UTC
  • 30 novembre, 20:00 UTC - 30 novembre, 22:00 UTC
  • 15 décembre, 20:00 UTC - 16 décembre 00:00 UTC
  • 5 janvier, 10.00 UTC - 5 janvier, 14.00 UTC
  • 13 janvier, 12.00 UTC - 13 janvier, 16.00 UTC
  • 18 janvier, 14.00 UTC - 18 janvier, 18.00 UTC
  • 24 janvier, 16.00 UTC - 24 janvier, 20.00 UTC
  • 1er février, 18.00 UTC - 1er février, 22.00 UTC
  • 7 février, 16.00 UTC - 7 février, 22.00 UTC
  • 13 février, 14.00 UTC - 13 février, 22.00 UTC
  • 21 février, 10.00 UTC - 21 février, 22.00 UTC
  • 28 février, 10.00 UTC - 28 février, 22.00 UTC
  • 6 mars, 00.00 UTC - Mars 7, 00.00 UTC
  • 13 mars, 00.00 UTC - Mars 14, 00.00 UTC
  • 21 mars, 00.00 UTC - Mars 22, 00.00 UTC

Étapes suivantes

Note

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édez à 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,

Aaron Hallberg