Je suis à peine commencé à utiliser Jenkins et c'est le premier problème que j'ai jusqu'à présent. Fondamentalement, mon travail de Jenkins réussit toujours même lorsqu'une erreur s'est produite dans certains des tests. C'est ce que je suis en cours dans la configuration Shell: est que Jenkins ne signale que des échecs lorsque la tâche qui échoue est la dernière. Par exemple, si je mettez "Test de rake: unités" la dernière tâche informera une erreur si quelque chose ne va pas. Utilisation de cette configuration, je n'ai que des rapports d'erreur pour les tests RSPEC mais pas pour les tests de l'unité. P> Quelqu'un se demande pourquoi je n'utilise pas seulement RSPEC ou test unitaire, nous migrent actuellement vers RSPEC, mais ce problème est Toujours douloureux. P> Cela fait partie du journal de Jenkinsm, car vous pouvez le constater que l'un des tests de l'unité échoue, mais Jenkins finit toujours avec succès. P> 314 tests, 1781 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [/var/lib/jenkins/.rvm/rubies/ruby-1.9.3-p1...]
Tasks: TOP => test:units
(See full trace by running task with --trace)
Lot of rspec tests here....
Finished in 3.84 seconds
88 examples, 0 failures, 42 pending
Pushing HEAD to branch master of origin repository
Pushing HEAD to branch master at repo origin
Finished: SUCCESS
3 Réponses :
Jenkins ne peut voir que le code de résultat de la dernière exécution de la commande afin qu'il n'a aucun moyen de savoir quel résultat de La chose la plus facile est probablement d'avoir une commande de ces commandes comme une étape de construction de Jenkins distincte. Rake Test: unités est.
Cette réponse est 100% correcte, mais je ne pense pas que ce soit une bonne idée de faire penser que chaque commandement est une étape de construction distincte est la meilleure pratique à Jenkins. Voir ma réponse ci-dessous.
Avoir une sous-étape pour chaque partie cassable du travail n'est pas une si mauvaise idée, tant qu'il est clair que chaque sous-étape est exécutée de manière autonome. Une autre option consiste à vérifier le résultat de chaque sous-étape dans la construction et sortie avec une erreur, si nécessaire.
Un inconvénient de cette solution est que si vous publiez des résultats de test (tels que le RSPEC Junitformatter + Jenkins Junit Editeur), avoir des étapes de script distinctes que chacune peut échouer la construction fera votre test de tendance à tester. tests suites ne fonctionne même pas. Je pense que @sti a une meilleure solution dans sa réponse.
Jenkins Exécute les commandes Vous tapez dans une zone de construction en les écrivant dans un fichier temporaire, puis en exécutant le script à l'aide de généralement cela produit l'effet souhaité: les commandes sont exécutées en séquence (et imprimée) et le script aborte immédiatement lorsqu'une commande échoue, c'est-à-dire éteindre le code de sortie non nul. P> Si cela ne se produit pas vous, la seule raison peut être que vous avez remplacé ce comportement. Vous pouvez le remplacer en démarrant la première ligne de votre étape de construction avec ces deux caractères: Par exemple, si votre étape de construction ressemble à ceci: p> / bin / sh -xe code>. #! Code>. p> #!/bin/bash
bundle install
rake db:migrate:reset
rake test:units
rake spec:models
Vous aviez raison, j'ai eu "#! / Bin / bash" comme première ligne :)
Si vous ajoutez #! / bin / bash -x Vous pouvez obtenir la pièce où Jenkins montre la commande qu'il s'exécute dans la sortie du script. Vraiment, c'est juste le -e que vous ne voulez pas de Jenkins 'code -xe
Une solution alternative change votre première ligne aux éléments suivants:
#!/bin/bash -e