Tutoriel sur l'intégration des packages RPM Linux avec Maven et Jenkins (Partie 2)

On trouve d'abord les attributs par défauts :

• droits d'accès des fichiers ;
• utilisateur propriétaire ;
• groupe propriétaire ;
• droits d'accès des dossiers.

Vient ensuite la liste des fichiers et dossier à embarquer, qui peuvent être modifiés au cas par cas : on ajoute par exemple des droits d'exécution sur le script de lancement de Sirkuttaa. Par défaut, tous les fichiers déclarés doivent être présents dans la buildroot, et réciproquement, tout fichier dans la buildroot doit être déclaré ici.

Ici le plugin prend le parti d'embarquer le dossier contenant les JAR plutôt que de les déclarer un par un. Le risque est d'embarquer dans le RPM des fichiers qui n'étaient pas prévus. Dans le cas d'un mvn clean package ce n'est pas grave, mais maintenant que nous allons construire le RPM à la main on va s'assurer de déclarer chaque fichier pour éviter les mauvaises surprises (mvn dependency:tree…), et puis si on oublie de mettre à jour la liste Jenkins ne manquera pas de nous le rappeler, c'est aussi son rôle.

%files
%defattr(644,root,root,755)

/usr/lib/sirkuttaa
/usr/lib/sirkuttaa/commons-io-2.3.jar
/usr/lib/sirkuttaa/jackson-core-asl-1.9.7.jar
/usr/lib/sirkuttaa/jackson-mapper-asl-1.9.7.jar
/usr/lib/sirkuttaa/sirkuttaa-1-1.jar

%attr(755,root,root) /usr/bin/sirkuttaa

%config(noreplace) /etc/sirkuttaa/default.properties
%config(noreplace) /etc/sysconfig/sirkuttaa

En dehors des fichiers, j'en profite pour compléter la liste des tags en début de spec, pour ajouter l'architecture cible, et une petite description. J'en profite aussi pour retirer certains tags qui, d'expérience, ne me serviront pas pour Sirkuttaa.

Name:      sirkuttaa
Version:   1
Release:   1
BuildArch: noarch
Summary:   The famous CLI Twitter client
License:   GPLv2+
Group:     Zenika/Blog
Packager:  Zenika
Requires:  java


%description
The ultimate command line experience for Twitter written in Java.

Maintenant, nous allons pouvoir renseigner les différentes sections de notre spec et créer notre RPM, mais avant ça, un petit mot sur les macros.

RPM propose un système de macros puissant, mais déroutant. Dans la première partie j'ai présenté quelques sections et leur syntaxe. On trouve par exemple %prep. Dans la section %files, on trouve aussi des directives dont la syntaxe est identique comme %dir ou paramétrée comme %attr(750,root,root). En plus des sections on peut déclarer des scriptlets, encore avec la même syntaxe (eg. %post).

À cela nous pouvons ajouter les macros, toujours avec des syntaxes similaires :

• %une_macro
• %{une_macro}
• %(du shell à exécuter)

On a beau utiliser systématiquement un %, on s'y retrouve très rapidement entre sections, scriptlets et macros. Avec un bon éditeur de texte (emacs, vim voire gedit) la coloration syntaxique facilite encore plus la lecture d'une spec.

Chaque installation de rpmbuild vient avec son lot de macros prédéfinies, pour faciliter certaines opérations et les rendre portables. On trouvera traditionnellement les macros %setup et %configure invoquées dans la section %prep, la macro %__make invoquée dans la section %build, parfois une exécution de %__make check dans la section %check et la macro %makeinstall dans la section %install. Sauf qu'ici on utilise Maven, donc, pourquoi ne pas créer nos propres macros pour garder ce niveau de simplicité ?

Un des inconvénients du packaging natif, c'est qu'il s'intègre moins bien avec les plateformes de plus haut niveau. On trouve par exemple en Java les packagings JARJava ARchive ou WARWeb ARchive, Maven va chercher lui-même ses dépendances, Ruby propose un système de gems… Je devrais donc en théorie ajouter une dépendance (BuildRequires NDLR) vers Maven, mais non. Trop de complications, je préfère partir de l'hypothèse qu'un développeur installera lui-même Maven, et que côté CIContinuous Integration c'est Jenkins qui mettra mvn dans le PATH. Tiens, Jenkins, encore une plateforme qui vient avec son propre packaging pour ses plugins.

Jenkins propose beaucoup de paquets natifs, y compris des RPM.

Cette petite digression terminée, on commence une intégration de Maven à la make. On va donc invoquer mvn dans les sections %prep, %build et %install. Il faudra aussi transmettre à Maven le numéro de version, et sans version, pas de build : premier réflexe, utiliser les mécanismes de properties. Pour émuler la macro %makeinstall, je n'ai rien trouvé de mieux qu'une assembly de type répertoire pour aller copier les fichiers directement dans la build root. Pour que le build Maven fonctionne en dehors de l'exécution de rpmbuild, j'ajoute des propriétés par défaut :

<properties>
    <project.rpm.version>dev</project.rpm.version>
    <project.rpm.installDirectory>${project.build.directory}/${project.artifactId}</project.rpm.installDirectory>
    <project.rpm.appendAssemblyId>true</project.rpm.appendAssemblyId>
</properties>

Côté rpmbuild, on transmet les propriétés en ligne de commande, et pour une intégration à la make je me crée quelques macros avec la macro %define :

%define mvn_opts -Dproject.rpm.version=%{version}-%{build_id} \\\
                 -Dproject.rpm.installDirectory=%{buildroot} \\\
                 -Dproject.rpm.appendAssemblyId=false

%define mvn mvn %{mvn_opts}

Il ne reste plus qu'à invoquer la macro %mvn, et j'ai opté pour le mapping section-phase suivant :

%prep
%{mvn} clean

%build
%{mvn} package

%install
%{mvn} verify

La configuration du maven-assembly-plugin avec les propriétés définies ci-dessus :

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>2.3</version>
    <configuration>
        <attach>false</attach>
        <finalName>/</finalName>
        <appendAssemblyId>${project.rpm.appendAssemblyId}</appendAssemblyId>
        <outputDirectory>${project.rpm.installDirectory}</outputDirectory>
        <descriptors>
            <descriptor>src/main/assembly/rpm.xml</descriptor>
        </descriptors>
    </configuration>
    <executions>
        <execution>
            <phase>verify</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Et enfin l'assembly correspondante (allégée grâce à la section %files de la spec) :

<assembly
    xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
        http://maven.apache.org/xsd/assembly-1.1.2.xsd">
 
    <id>rpm</id>
 
    <formats>
        <format>dir</format>
    </formats>
 
    <includeBaseDirectory>false</includeBaseDirectory>
 
    <fileSets>
        <fileSet>
            <directory>src/main/scripts</directory>
            <outputDirectory>/usr/bin</outputDirectory>
        </fileSet>
        <fileSet>
            <directory>src/main/config</directory>
            <outputDirectory>/etc</outputDirectory>
        </fileSet>
    </fileSets>
 
    <dependencySets>
        <dependencySet>
            <outputDirectory>/usr/lib/${project.artifactId}</outputDirectory>
        </dependencySet>
    </dependencySets>
</assembly>

J'ai pris le parti d'invoquer %mvn verify dans la section %install, car aucune section ne lui correspond réellement. En attendant la dernière phase pour générer l'assembly, c'est du temps gagné côté développement lorsqu'on veut juste construire son JAR/WAR ou exécuter les tests d'intégration. Les phases install et deploy perdent aussi de l'intérêt avec cette approche. C'est plutôt le RPM que je chercherai à archiver. Côté intégration continue d'ailleurs, le principe de snapshot Maven a disparu, et n'existe plus que du côté développeur.

La gestion des versions n'est pas vraiment abordée dans cet article, et dans le cas de Sirkuttaa, c'est en dur dans la spec. Attention cependant, le numéro de version complet se compose du duo %{version}-%{release}. Pour la partie release on peut utiliser la variable d'environnement BUILD_NUMBER de Jenkins.

Pour plus de fiabilités, je vais utiliser la variable BUILD_ID. On pourrait récupérer cette valeur facilement avec la macro %(echo $BUILD_ID), mais je préfère créer un script de build indépendant qui puisse être exécuté en dehors de Jenkins. Au passage, l'utilisation du plugin ZenTimestamp devient indispensable car par défaut le BUILD_ID contient des tirets.

Le seul réel point noir dans la gestion des versions, c'est que Maven ne fonctionne pas sans. De mon point de vue, le périmètre de Maven est beaucoup trop large et certains aspects (même lorsqu'ils sont issus de plugins) débordent du simple build (au hasard les releases ou la création de site). Du coup Maven nous avertit qu'il n'apprécie pas du tout notre hack et qu'à terme il ne fonctionnerait plus :

[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.zenika.blog.rpm:sirkuttaa:jar:1-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @ com.zenika.blog.rpm:sirkuttaa:${project.rpm.version}, pom.xml, line 10, column 11
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

En attendant certains outils de build comme Gradle s'en sortent très bien avec un numéro de version transmis en ligne de commande.

Une chose qu'il faut savoir avec rpmbuild, c'est que le répertoire de travail (par exemple ~/rpmbuild) est partagé par défaut par les différentes specs, il correspond à la macro %_topdir. Dans l'arborescence, certains dossiers seront partagés par les différentes specs alors que d'autres seront spécifiques à une version spécifique d'une spec. Une des choses que j'apprécie avec Maven, c'est que tout se passe par défaut dans un dossier target et qu'on peut supprimer (mvn clean) ce dossier en toute sécurité. On va donc faire pareil pour notre construction de RPM (ce que fait le rpm-maven-plugin au passage) mais de façon moins radicale : on ne redéfinit que les dossiers utilisés (macros %_rpmdir et %_builddir).

L'intégration avec Jenkins consiste en fait à réutiliser l'environnement fourni par Jenkins. La variable BUILD_ID a déjà été évoquée, j'utilise également la variable WORKSPACE pour atteindre le dossier $WORKSPACE/target de Maven. Par défaut rpmbuild va créer le RPM dans un sous-dossier noarch, qui correspond à l'architecture cible. Une dernière chose, je configure manuellement l'archivage des RPM générés avec le pattern target/noarch/*.rpm.