J'ai une configuration de construction dans TFS 2013 qui produit des artefacts de construction versionnés. Cette version utilise le flux de travail de modèle de processus hors du boîtier. Je tiens à détruire les artefacts de construction dans le cas où les tests d'unités n'échouent que les fichiers journaux. J'ai un script PowerShell post-test. Comment détecter l'échec du test dans ce script?
Voici la méthode de nettoyage correspondante dans mon script post-test: Comment puis-je tester pour tester le succès la fonction?
3 Réponses :
Ce n'est pas une réponse directe, mais ... nous venons de définir la politique de conservation pour ne conserver que x nombre de constructions. Si les tests échouent, les artefacts ne sont pas poussés à la prochaine étape.
Avec notre configuration Jenkins, il essuie les artefacts chaque nouvelle construction de toute façon, de sorte que ce n'est pas un problème. Seuls les constructions de passage incendient l'étape pour pousser les artefacts au serveur de nuge Octopus.
Ouais tristement im dans un lieu de travail client et ceci est là environnement.
(mise à jour basée sur plus d'informations)
Le moyen de faire cela consiste à utiliser des variables d'environnement et à les lire dans votre script PowerShell. Malheureusement, les scripts PowerShell sont gérés dans un nouveau processus à chaque fois pour que vous ne puissiez pas compter sur les variables d'environnement remplacées.
Cela dit, il y a une solution de contournement afin que vous puissiez toujours obtenir ces valeurs. Il s'agit d'appeler un petit utilitaire au début de votre script PowerShell comme décrit dans ce blog Post: http://blogs.msmvps.com/vstsblog/2014/05/20/dgetage- The-Compile-Test-Statut-Statut-AS-Environnement-Variables - Lorsque-s'étend-tf-build-utilise-scripts /
Les essais sont une étape du modèle de construction de l'équipe. Le script PowerShell s'appelle via le gabarit également après la fin de l'exécution du test.
Cela semble faire l'affaire. On dirait une énorme Miss de l'équipe de construction de l'équipe TFS. Si j'exécute un test de script post-test, il est logique que je souhaiterais accéder aux résultats du test dans ce script. En outre, il a un peu singuleux de télécharger un fichier ZIP Formulaire de formulaire de déplacement aléatoire .NET Blog hébergé sur un autre blog de développeurs aléatoires .NET et qu'attendu que quiconque l'utilise. J'ai goûté avec Dotceek et on dirait que l'Assemblée a des références au système d'analyse de Telerik. Il n'y a pas de notification de celle nulle part dans le blog Publier ou dans le téléchargement. Cela n'inspire pas vraiment la confiance.
Je pense que je vais répondre à l'affiche la suggestion qu'ils opensource cet outil set et le rendent disponible via Nuget.
@NotmySelf Je suis totalement d'accord, cela devrait être plus facile à faire. Une fois que j'ai fait cela, au moins je devais avoir du mal à passer de variables d'envioment d'une batte à PowerShell. Heureusement, j'ai trouvé cet autre thread Stackoverflow .com / questions / 4384814 / ... espère que je sauve une personne les deux heures que j'ai passées à ce sujet
Le moyen le plus simple possible (sans personnaliser le modèle de construction, etc.) est comme celui-ci dans votre script post-test:
$testRunSucceeded = (sqlcmd -S .\sqlexpress -U sqlloginname -P passw0rd -d Tfs_DefaultCollection -Q "select State from tbl_TestRun where BuildNumber='$Env:TF_BUILD_BUILDURI'" -h-1)[0].Trim() -eq "3"
Peut-être qu'un jour Microsoft publiera une API de repos d'agrément qui offrira un accès aux informations de test / résultat. Ne tenez pas votre souffle si vous avez attendu six ans jusqu'à présent. Entre-temps, frapper directement le TFS DB est un moyen sûr et fiable de le faire. P>
J'espère que c'est d'une certaine utilisation. p> p>
Voulez-vous dire cette API de repos? VisualStudio.com/en-us/Integrate/ Référence / ...
Hein, c'est une solution de contournement intéressante. Je vais le garder dans ma poche arrière.
Oui, @Richardbanks, mais non - ce n'est pas disponible dans le produit sur site.
L'échec étant si certains des répertoires ne sont pas supprimés et que le répertoire n'est pas vraiment vide? Ou juste une erreur de la
supprimer-item cmdlet?La défaillance étant un test d'unité a échoué pendant le test de l'unité.