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 Réponses :
Ç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}"
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}" code> et
- définir = "libérer $ {build_number}" code> 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}" code>, puis utilisez votre réponse. Merci!!
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> 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 ./*)
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: p> et dans les Jenkins Construire un script: p> Le résultat est que je reçois le schéma de versions de package suivant: p> 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é. p> p> rpm-release-number.py code> 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 . P>
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: 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
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é.