8
votes

Utilisation de Jenkins Build Numéro dans le fichier de spécifications RPM

Name:                   My Software
Version:                1.0.5
Release:                1
Summary:                This is my software
Not sure if anyone has tried this before or if it is easy, but:A spec file has two unique indicators for its version:
Version (which specifies software version)
Release (which specifies the package's number - if you build an RPM, it's broken, and build another one, you up the 'Release' number.
I'm wondering if anyone has tried, or knows how, I could use the Jenkins $BUILD_NUMBER variable to dynamically change the Release number, thereby increasing the Release number every time a new successful build completes...?

4 commentaires

Sed -i "s / version / $ build_number /" rpm.spec


Vous ne voulez pas voir le fichier .spec ... il (devrait) être sous contrôle source, de sorte que la construction ne doit pas le changer.


Essayez FPM , tant mieux que les fichiers spécifiques 80% du temps!


Hmm. Devra regarder dans la FPM. Jusqu'à présent, la méthode mentionnée par @Thekbb a travaillé.


4 Réponses :


7
votes

Ça fait longtemps ... et heureusement, je n'ai aucun système basé sur RPM, je ne peux donc pas tester cela.

Vous pouvez passer des paramètres à RPMBUILD CODE> sur la commande Commandline P>

rpmbuild --define="version ${env.BUILD_NUMBER}"


4 commentaires

Le fichier de spécification est dans le contrôle de la source, oui. Je comprends le besoin de ne rien changer dans le fichier de spécification à l'aide du script de construction. D'autre part, chaque fois que nous avons une construction, je dois changer le fichier de spécifications manuellement et le vérifier et effectuer toutes les autres modifications associées. Avoir cela changera automatiquement le rendrait tellement plus facile ...: \


Oui ... c'est pourquoi vous avez la construire la réussite et laissez simplement une valeur faux dans le fichier de spécifications, comme 9.9.9-1, il sera donc très évident que la construction n'a pas injecté la version appropriée


Cela n'a pas fonctionné. J'ai essayé les deux - définir = "version = $ {build_number}" et - définir = "libérer $ {build_number}" comme mentionné dans l'aide RPMBuild.


J'ai compris. Je devais changer la valeur de "libération" pour être une macro. Fondamentalement, changez la ligne vers "version:% {version}" , puis utilisez votre réponse. Merci!!



3
votes

J'utilise le numéro de construction Jenkins en tant que "version" et emballage via FPM . couple fpm avec quelques globaux fournis par Jenkins p> xxx pré>

Il existe des variables nébuleuses dans l'exemple de commande ci-dessous, mais $ build_number code> est ce que je suis Utilisation de la version em> ici (appelle FPM IT itération em> à la place). P>

fpm_out=$(fpm -a all -n $real_pkg_name -v $version -t rpm -s dir --iteration $BUILD_NUMBER ./*)


0 commentaires

3
votes

Dans ma configuration de Jenkins, j'ai décidé de contourner le numéro de construction en ce qui concerne la numérotation de la version RPM complètement. Au lieu de cela, j'utilise un script fabriqué à la maison qui génère et conserve la trace des différentes sorties générées.

dans mon fichier spécifique: xxx

et dans les Jenkins Construire un script: xxx

rpm-release-number.py est un script simple qui gère une base de données basée sur un fichier (au format JSON, pour faciliter maintenance). Il peut gérer d'être couru en même temps, alors pas de soucis là-bas, mais cela ne fonctionnera pas si vous avez des esclaves de construction (autant que je sache, je ne les utilise pas, je ne peux pas tester). Vous pouvez trouver le code source et la documentation ici .

Le résultat est que je reçois le schéma de versions de package suivant: xxx

PS: Notez que le script de construction Jenkins n'est qu'un exemple, la logique Dès la création de la structure de répertoire RPMBuild et la récupération des noms de fichier .src.rpm et .spec est un peu plus compliqué.


0 commentaires

-1
votes

Prenant en compte que le fichier de spécification pourrait être tiers, je préfère faire de pré-construire le cartage de la zone de libération: xxx pré>

ici % {expand: ... } code> macro est utilisé pour gérer les numéros de libération définis macro comme ceux des spécifications Magea: p>

sed -i 's/^Release:\(\s*\)\(.*\)$/Release:\1'$BUILD_NUM'.%{expand:\2}/g' ./path/to/spec
rpmbuild -ba ./path/to/spec


0 commentaires