TReqS

Sujet : Automatiser la disponibilite des dernieres versions des libs (et includes) HPSS.

Memo : Pas si simple à faire et pas justifié vu que les versions de lib evoluent très peu
       Je note ici nos réflexions, c'est tout.
Solutions :

1/ Exprimer les lib HPSS en un packaging sauce maven  et
   exprimer la dependance au niveau  du projet

+ : ca suit le job
- : l'env. de build ne sera pas exactement l'env d'exécution
     (cf ~/.m2/...   versus le /opt/lib à l'execution)
    il faut que les libs hpss supporte le versionning
     system-dependant
     le travail à fournir me parait important

2/ Definir un template "hpss" pour instancier une image selon ce template

+ Une fois le template défini, l'utilisateur jenkins est autonome
- A chaque version de libhpss, il te faudra recréer une image avec les nouvelles libs.
   PAs de droits particulier ?

3/ Utiliser le template "ubuntu" + script post-init

+ evite de faire un template dédié à ton job... c'est un peu léger comme avantage.
- il faut être root pour le post-init
   chaque nouvelle lib hpss necessite un jenkins admin

4/ Faire les choses au niveau du job (jenkins)
   recup des libs dans le workspace jenkins

+ autonomie (pas besoin d'accès root, ni d'esclave particulier)
- nécessaire d'avoir les libs/include packagés sur HTTP.

Remarques | Question :
  Il faut que les lib hpss soit dispos qq part (typiquement le web)
Sauf avec la solution 5:

5/ créer un job de build hpss qui fait:
- git clone (ou CVS ou SVN...)
- make && make install
et faire dépendre ton job de ce job (lorsque tu build ton job, le job de hpss sera exécuté en amont).
Cette solution nécessite que HPSS puisse être buildé de façon standard (et nécessite un accès au SCM).
A demander aux hpssmaster.

+ autonomie, tu configures tout toi même.
- hpss sera buildé à chaque fois donc le build sera un peu + long

Selon Lionel : 
 je privilègerais la solution 4/ ou 5/
 Maintenant, si les libs hpss changent vraiment très rarememt, peut-être que la solution 2/ est la moins couteuse