Jacoco ne génère pas de rapport via Sonar

Rédigé par gorki - - Aucun commentaire

Le problème :

Configuration du job Jenkins pour Sonar avec les arguments Jacoco :

clean org.jacoco:jacoco-maven-plugin:prepare-agent install -Dmaven.test.failure.ignore=true

Et pourtant pas de couverture de code à la fin de l'exécution du build sonar.

Solution :

Simple quand on connait la réponse, conflit entre  :

  • les arguments dans le pom.xml du plugin Surefire
  • les arguements en ligne de commande du plugin Jacoco.

Du coup, les <argLine> du plugin Surefire dans le pom.xml doivent référencer la variable ${argLine}

 <argLine>-server -ea -XX:MaxPermSize=256m -Xmx4g -XX:-UseSplitVerifier ${argLine}</argLine> 

Extrait de stackoverflow

 

Jenkins et déploiement automatique

Rédigé par gorki - - Aucun commentaire

Le problème :

Déployer à partir de Jenkins, une application fraichement buildée sur des serveurs distants (avec des scripts en tout genre, mise à jour bdd, fichiers, autres)

Solution :

Il est possible de tout faire dans Jenkins à l'aide des plugins (Publish over SSH et SSH Credentials), mais c'est fastidieux et lent de tester/maintenir ses scripts ainsi.

Je préfère, et de loin, avoir mes scripts disponibles sous un shell pour les tester efficacement et pourquoi pas, les réutiliser ailleurs. Dans ce cas, le plugin de base pour exécuter un script suffit.

Quelques problèmes se sont posés, d'où quelques bonnes pratiques à avoir :

  1. utiliser des clés publiques / clés privées pour ne pas avoir à gérer les mots de passe dans Jenkins.
  2. séparer les jobs de builds des jobs deploy et les organiser avec MultiJob
  3. stocker les scripts sous votre SVN / Git (Jenkins permet de déployer une arborescence dans un sous-répertoire)
    • par exemple : url SVN des scripts => à extraire dans ./deploy
  4. dans la partie build : déterminer automatiquement la version et stocker là dans un fichier. Cela permet de pointer sur le trunk plus facilement
  5. dans la partie deploy :
    • retourner un code à Jenkins en fin de script pour indiquer si le build est OK ou KO
    • utiliser les variables d'environnements locales (Jenkins), distantes.
# tracer l’environnement local (script Jenkins) avec 
env > /path/to/env_jenkins.txt

# tracer l'environnement distant avec : 
ssh $SERVEUR_DIST << FIN
	env > ~/env_distant.txt
FIN

# passer les variables d'un environnement à l'autre (bash remplace les variable locales (Jenkins) au moment de transférer le script) :
ssh $SERVEUR_DIST << FIN
	echo $VARIABLE_JENKINS
	echo \$VARIABLE_DISTANT
FIN
  • comme tout bon script :
    • tester les arguments
    • mettez des logs
    • mettez des messages d'erreurs clairs
    • tester les codes retours de vos commandes : ça ne coute rien !
if [ $? -ne 0 ] ; then exit 1; fi

Merci capt'ain Obvious dirons-nous, mais au moins c'est écrit.
En effet toute cette artillerie peut avoir à fonctionner toutes les nuits, ça merdera forcément, autant que la panne soit facile à identifier.

 

 

Fil RSS des articles de ce mot clé