JENKINS est un ordonnanceur de tache, dédié à l'intégration continue. Le principe de base est surtout le suivant : A chaque push d'un commit effectué sur une branche d'un repo git :

1. jenkins scanne et identifie le nouveau commit
2. il pull la branche
3. il lance une action de build (soit avec des commandes maven, shell, DOS, …)

JENKINS est mise en oeuvre par une appli web, servie par un moteur tomcat. Il existe aussi un outil (jar) en ligne de commande (voir plus bas).

Disposer de tomcat >= 7

  sudo apt list --installed 2>&1 | grep tomc
  sudo apt-get remove tomcat6
  sudo apt-get install tomcat7

• Télécharger un des war sur le site de jenkins
• Placer le pour qu'il soit ici : /var/lib/tomcat7/webapps/jenkins.war

ou dezziper le contenu du war pour faire le dossier /var/lib/tomcat7/webapps/jenkins

Si le war est récent, il est compilé avec une version récente de java. /usr/bin/java du raspberry est un lien symbolique vers une des alternatives de JDK installées sur le raspberry.

  $ ls -l /usr/bin/java

lrwxrwxrwx 1 root root 22 mai 7 2015 /usr/bin/java → /etc/alternatives/java

  $ ls -l /etc/alternatives/java

lrwxrwxrwx 1 root root 51 déc. 28 21:08 /etc/alternatives/java → /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt/jre/bin/java

=⇒ Il est possible de faire pointer ce lien symbolique sur une autre alternative en tappant les 2 commandes suivantes :

  sudo update-alternatives --config java

  sudo update-alternatives --config javac

Chacune des exécutions demandera quelle version utiliser.

tomcat utilise java, qui utilise un truststore bien connu : cacerts. Il s'agira de celui de la jdk de la jre utilisée pour lancer tomcat. JENKINS utilise par défaut un site web pour aller récupérer les plugins à installer. Le site par défaut est : https://updates.jenkins.io/update-center.json

Malheureusement, sa chaine de certification SSL n'est pas dans cacerts. Il faut donc récupérer le certificat racine et intermédiaire de la chaine de certification, en ouvrant un navigateur internet et en exportant les certificats au format base64. On créé les fichiers CA_Intermediaire.pem et CA_Racine.pem. Ensuite, on les importe dans le truststore cacerts de la manière suivante :

Les fichiers sont http://xms_rbpi/certificatSSLPourJenkins2018/CA_Racine.pem et http://xms_rbpi/certificatSSLPourJenkins2018/CA_Intermediaire.pem

  sudo keytool -import -alias PourJenkinsIntermediaire -keystore /usr/lib/jvm/java-8-oracle/jre/lib/security/cacerts -file /home/debian/certificatSSLPourJenkins2018/CA_Intermediaire.pem

  sudo keytool -import -alias PourJenkinsRoot  -keystore /usr/lib/jvm/java-8-oracle/jre/lib/security/cacerts -file /home/debian/certificatSSLPourJenkins2018/CA_Racine.pem

Remarque : le mot de passe par défaut de cacerts est 'changeit', sans guillemet.

Aller dans la conf de tomcat, editer server.xml et remplacer son port 8080 par un port qui n'est pas et ne sera pas en écoute à part celui de tomcat.

Ca ce lance en lancant tomcat du coup.

 sudo service tomcat7 start
 
 sudo service tomcat7 status

La première fois que jenkins est lancé, la webapp génèrera un mot de passe pour le compte admin. Elle le placera dans /usr/share/tomcat7/.jenkins/secrets/initialAdminPassword.

Tapper la commande suivante pour prendre le mot de passe :

 cat /usr/share/tomcat7/.jenkins/secrets/initialAdminPassword

Il sera biensur possible de redéfinir son mot de passe par la suite, dans la configuration du compte.

Mon jenkins home est /var/lib/tomcat/jenkins \

Il faut s'assurer qu'il soit en rwx partout et appartienne à tomcat:tomcat

Dans le fichier /etc/tomcat9/context.xml, dans la balise contexte ajouter la ligne suivante :

 <Environment name=”JENKINS_HOME” value=”/var/lib/jenkins” type=”java.lang.String” />

java.nio.file.FileSystemException : le système de fichiers en lecture seule apparaît dans tomcat9 \

Trouver et éditer le fichier tomcat9.service (moi il était dans /usr/lib/systemd/system) \ puis ajouter la ligne suivante :

  ReadWritePaths=/le chemin de jenkins home   (pour moi, c'est /var/lib/tomcat/jenkins)

Enfin, recharger le system de mise à jour des service

 systemctl daemon-reload

Puis relancer tomcat

 service tomcat restart 

Dans le fichier /etc/tomcat9/context.xml, dans la balise contexte ajouter la ligne suivante :

  <Resources cacheMaxSize="51200" />

Il se situe dans /usr/share/tomcat7/.jenkins : On y retrouve notamment les projets de build :

1. Le contenu copie de travail des repo GIT
2. Les logs générés par les builds, etc …

• Aller dans le gestionnaire de plugin, cocher le plugin Github (attention, il y en a plusieurs, prendre le bon).
• Attendre que jenkins installe les plugins et redémarre.

Après cela, vous verrez que vous créér un nouvel item, vous disposerez d'options SCM.

Créer un nouvel item, en sélectionnant SCM, git Ensuite, saisir le repo git (par exemple : https://github.com/newman79/scripts.git)

Puis cliquer sur ajouter credentials, et saisir ses identifiants github ( exemple : xavier.marquis@gmail.com/)

Ensuite choisir la branche (exemple : */master)

Puis cliquer sur ajouter.

Plus bas, dans ce qui déclenche le build, cocher 'Scrutation de l'outil de gestion de version'. Et saisir dans le champs Planning * * * * * (pour un scan toutes les minutes)

Enfin, créer autant de taches que vous souhaitez pour ce build

Puis cliquez sur “sauver”.

Maintenant, à chaque push de commit sur la branche de votre repo distant, jenkins lancera le build que vous venez de créer :

1. il pullera la branche dans /usr/share/tomcat7/.jenkins/workspace/<NomDeVotreRepo>
2. puis il lancera les taches que vous avez spécifiées

Il existe aussi un outil en ligne de commande permettant de script les opérations de maintenance : jenkins-cli.jar

Pour obtenir l'aide :

 java -jar jenkins-cli.jar -s http://jenkins:8080/ help

Les Jenkins file permettent en gros de décrire les actions de build qu'on configure habituellement dans un build de jenkins.

• Les jenkins file sont écrits en groovy

• Une particularité chez RTE est qu'un script groovy peut tirer/se servir d'une librairie groovy.Cela se fait au début du script groovy via :

@Library('pipeline-devin@02.14.03')Il existe donc chez RTE un projet gitlab nommé pipeline-devin, qui permet de consulter la documentation des méthodes publiées. Cette librairie contient des meta-méthodes stageDevin()

• Dans un script groovy, il est possible d'accéder aux paramètres de build (parametre qui doivent être renseigné à chaque lancement de build) via le mot clé params