Nunit: Utiliser Azure Pipelines au lieu de Travis (et peut-être d'autres builds) ?

Si quelqu'un était suffisamment intéressé pour le mettre en place, j'aimerais que nous l'utilisions d'abord aux côtés de Travis pendant un certain temps, avant de prendre une décision. Juste pour être sûr que cela n'a pas les mêmes problèmes de fiabilité pour OSX que Travis.

Ça a l'air cool quand même ! ??

Bonne idée. J'aimerais que nous utilisions davantage les versions là-bas et éventuellement les versions. Si quelqu'un veut intervenir, je me suis assuré que @ChrisMaddock et @jnm2 sont tous deux administrateurs de projet de https://nunit.visualstudio.com/NUnit/. Si un autre membre de @nunit/framework-and-engine-team souhaite nous aider avec nos builds Azure Pipeline, faites-le moi savoir.

J'ai un peu avancé là-dessus ce soir. J'ai amélioré la version existante de Windows CI pour la construction, le test et le package. J'ai également la version macOS qui fait la même chose bien que j'obtienne un échec de test cohérent sur macOS. Ce qui est bien, c'est que je publie les résultats des tests, vous n'avez donc pas besoin de scanner les journaux pour voir les échecs des tests !

Je travaille sur la version Linux. J'ai du mal à installer une version 1.1 et 2.0 de .NET Core sur les agents de build...

Linux fonctionne maintenant. J'avais juste besoin de passer des tâches Utiliser la version .NET Core à une tâche générale qui effectue un apt-get install de la version qui manquait.

Toutes les versions sur toutes les plates-formes effectuent une construction, un test et un package, puis publient en tant qu'artefacts. Ils construisent actuellement sans numéros de build de développement comme sur AppVeyor. Nous devrions mettre à jour le script Cake pour faire un IsRunningOnVSTS et utiliser la même logique que sur AppVeyor.

Une fois que nous arrivons à cette étape, j'aimerais passer à l'étape suivante consistant à créer les modifications de la branche de publication et à les déployer/publier automatiquement. Nous devrons réfléchir à la façon dont nous maintenons les notes de version et le changes.txt à ce stade. Automatiser toutes les choses ?

@mikkelbu Je vous ai ajouté en tant qu'autre membre de l'équipe du projet DevOps Pipeline (alias VSTS), vous devriez donc pouvoir entrer et apporter des modifications si nécessaire. Faites-moi savoir si vous rencontrez des problèmes d'autorisations et je corrigerai.

Toutes les builds Azure signalent actuellement un succès alors qu'elles devraient signaler un échec.

Discussion intéressante ici. Je suis PM dans l'équipe Azure Pipelines. N'hésitez pas à me contacter pour toute question.

@chrisrpatterson J'ai une question, si vous me le réponds là-dessus. Je m'excuse, c'est un peu long pour être clair.

Problème

Nous avons 18 tests que nous aimerions publier, 6 pour chaque système d'exploitation (voir liste) .
(La raison pour laquelle le nombre ne peut pas être inférieur à 18 est que ces tests ont exactement les mêmes noms. Chaque test s'exécute 18 fois, couvrant chaque combinaison de système d'exploitation et de framework cible. Si nous allions avec moins de téléchargements de tests, Azure DevOps fusionnerait le tests avec les mêmes noms et nous ne serions pas en mesure de dire pour quel système d'exploitation et framework cible le test a échoué.)

La tâche « Publier les résultats des tests » ne prend en charge que la création d'une seule exécution de test. Par conséquent, si nous avons 18 exécutions de test, nous devons répéter ce bloc 18 fois dans notre YAML :

  - task: PublishTestResults<strong i="12">@2</strong>
    displayName: Publish test results
    inputs:
      testResultsFormat: NUnit
      testResultsFiles: test-results\net45\*.xml
      mergeTestResults: true
      testRunTitle: net45/Windows
    condition: succeededOrFailed()

Cela rend le YAML dense et difficile à lire. En outre, les six cadres cibles spécifiques que nous soutenons peuvent changer à l'avenir. Nous oublierons invariablement que nous avons ce couplage avec les chemins test-results\net45\*.xml spécifiques et n'oublierons de corriger le YAML qu'une fois que nous remarquons que les résultats des tests sont manquants. Ce n'est juste pas très satisfaisant.

Tentative d'automatisation

Étant donné que nous utilisons un script de génération Cake, il semble être une bonne idée d'automatiser ces téléchargements en utilisant C# pour l'imprimer dès que chaque ensemble de fichiers est prêt, tout comme la tâche « Publier les résultats du test » :

##vso[results.publish type=NUnit;mergeResults=true;config='Release';runTitle='netcoreapp2.0/Windows';publishRunAttachments=true;resultFiles=D:\a\1\s\test-results\netcoreapp2.0\nunit.framework.tests.xml,D:\a\1\s\test-results\netcoreapp2.0\nunitlite.tests.xml]

Publier à partir de nos propres scripts au lieu de publier à l'aide de la tâche « Publier les résultats du test » présente des avantages considérables :

• Nous n'avons pas à répéter ce morceau de YAML 18 fois. Le YAML est maintenant facile à lire. De plus, nous n'aurons pas à exclure six frameworks spécifiques correspondants dans le YAML, nous n'aurons donc pas de résultats de test manquants si nous ajoutons un framework cible car nous avons oublié de mettre à jour le fichier YAML.

• Nous pouvons regarder les résultats des tests arriver au fur et à mesure que chacune des exécutions de test se termine, plutôt que d'attendre que l'étape « PowerShell » soit terminée, puis de faire l'étape « Publier les résultats des tests ». C'est moins essentiel, mais c'est une fonctionnalité intéressante qui ne serait jamais possible lors de l'utilisation de la tâche « Publier les résultats des tests » pour publier les résultats des tests.

Problème de tentative d'automatisation

➡ Cela ne fonctionne que si les tâches de build récupèrent les agents v2 hors de la file d'attente. La plupart du temps, la version Windows récupère un agent v1 qui ignore totalement la commande de journalisation ##vso[results.publish...] .

Comment la tâche « Publier les résultats du test » résout-elle normalement ce problème ? Il empêche les agents v1 d'être récupérés car il a un task.json qui spécifie "minimumAgentVersion": "2.0.0" .

Il n'y a pas d'équivalent de minimumAgentVersion pour nos azure-pipelines.yml . Le mieux que les pipelines YAML puissent faire est de demands: agent.version -equals 2.142.2 ou quelle que soit la version exacte de l'agent aujourd'hui, mais cela s'interrompt dès que les agents sont mis à jour vers la version 2.142.3. Donc ce n'est pas bon.

La seule façon d'obtenir un agent avec une version supérieure ou égale à 2.0.0 est d'ajouter une tâche factice « Publier les résultats des tests » qui ne télécharge rien et laisse des avertissements dans nos résumés de build, ou bien d'abandonner l'idée d'automatisation et de revenir à les 18 variantes de ce bloc de YAML dans notre azure-pipelines.yml :

  - task: PublishTestResults<strong i="5">@2</strong>
    displayName: Publish test results
    inputs:
      testResultsFormat: NUnit
      testResultsFiles: test-results\net45\*.xml # Or net 40, or 5 others
      mergeTestResults: true
      testRunTitle: net45/Windows # Or net40/Linux, or 16 others
    condition: succeededOrFailed()

J'ai trouvé cette demande qui est marquée Closed - Not Enough Info : https://developercommunity.visualstudio.com/content/problem/75687/build-demands-agentversion-gtversion-21020.html

C'est donc moi qui m'efforce de fournir plus d'informations. Est-ce que cela a été utile? Souhaitez-vous que je déplace ma question vers un meilleur forum? À moins que votre équipe ne connaisse des solutions de contournement, nous opterons probablement pour la voie des 18 copies de YAML banal.

Merci beaucoup!

@chrisrpatterson, je m'excuse de vous avoir

@jnm2 L'exemple d'automatisation que vous avez semble bien. Je suis curieux de savoir comment vous avez des agents V1 car ils ne sont plus vraiment pris en charge. Il ne doit pas non plus y avoir d'agents v1 dans le pool hébergé.

@chrisrpatterson Les agents v1 faisaient leur apparition fin novembre :

Le téléchargement des résultats des tests n'a lieu que si les tâches se produisent sur les bons agents. Quand cela fonctionne, il indique "Agent : Hosted VS2017 2". En cas d'échec, le message "Agent : Agent hébergé" s'affiche. Similaire pour Linux et macOS.

Je me demande si c'est ce qui se passe :

https://github.com/Microsoft/azure-pipelines-tasks/blob/f8526d84cde186125cc589433fb950d437d1ef77/Tasks/PublishTestResultsV2/task.json#L20

"minimumAgentVersion": "2.0.0"

Maintenant que je n'utilise pas task: PublishTestResults@2 dans le YAML, cela ne nécessite pas d'agents capables.

Je ne savais pas que c'était un problème ponctuel, mais c'est logique. Je vais réessayer la voie d'automatisation. Merci pour l'info!

Fermez ceci comme fait.

@chrispat je m'excuse ! Je pense avoir compris ce qui se passait.

Le téléchargement des résultats des tests n'a lieu que si les tâches se produisent sur les bons agents. Quand cela fonctionne, il indique "Agent : Hosted VS2017 2". En cas d'échec, le message "Agent : Agent hébergé" s'affiche. Similaire pour Linux et macOS.

J'utilisais IsRunningOnTFS Cake qui renvoie false si AGENT_NAME commence par "Hosted" ! La raison pour laquelle les résultats des tests ne s'affichaient pas n'avait rien à voir avec la version de l'agent, mais plutôt la vérification de Cake n'étant pas fiable et notre script pensant qu'il n'était pas sur Azure Pipelines et donc n'imprimait même pas ##vso[results.publish etc.

Ma faute de ne pas avoir vu ça plus tôt. Merci beaucoup pour votre aide!