Quelle partie de HUDSON_HOME dois-je mettre sous contrôle de source?

Question

Je voudrais gérer les fichiers de configuration de Hudson avec subversion pour la sauvegarde. Le Wiki de Hudson répertorie la structure de répertoires de $ HUDSON_HOME de la manière suivante:

HUDSON_HOME
 +- config.xml     (hudson root configuration)
 +- *.xml          (other site-wide configuration files)
 +- fingerprints   (stores fingerprint records)
 +- plugins        (stores plugins)
 +- jobs
     +- [JOBNAME]      (sub directory for each job)
         +- config.xml     (job configuration file)
         +- workspace      (working directory for the version control system)
         +- latest         (symbolic link to the last successful build)
         +- builds
             +- [BUILD_ID]     (for each build)
                 +- build.xml      (build result summary)
                 +- log            (log file)
                 +- changelog.xml  (change log)

Il est évident que jobs / [JOBNAME] / builds ne doivent pas entrer dans le contrôle de code source, mais config.xml est un bon candidat. Les plugins et les empreintes digitales sont moins évidents.

Comment gérez-vous vos configurations Hudson?

Answer 1

J'utilise un GDS pour gérer ma configuration Hudson. Je conserve les fichiers config.xml et config.xml de niveau supérieur pour chaque travail. J'ai un petit script que j'utilise pour récupérer les configs de Hudson et les valider / ajouter / les supprimer si nécessaire (avec quelques autres options facilitant la gestion de la configuration).

Points de Rob Hruska, pour ma configuration particulière:

• les configurations changent souvent (notifications, en particulier)
• (voir ci-dessus un script pour effectuer les mises à jour)
• Je diffère des choses tout le temps. Nous avons plus d’un administrateur qui peut mettre à jour la configuration, et ces différences sont utiles

Cela étant dit, chaque situation est différente. La gestion que je fais pour les configs n'est pas (et ne) pas venue gratuitement. Un travail cron qui ferme tout le soir est certainement moins cher et peut également suffire.

Answer 2

Un SCM n’est probablement pas le meilleur outil pour sauvegarder l’espace de travail de Hudson - c’est comme utiliser une Subversion pour stocker les préférences d’un jeu ou le contenu des tables de base de données d’une application Web. Parallèlement à cela, cela ne semble pas nécessaire pour les raisons suivantes:

• Les fichiers de configuration ne changent pas (ou ne devraient pas) changer fréquemment (comme le code), donc les sauvegardes nocturnes sont suffisantes.
• Lorsque vous apportez des modifications via l'interface graphique, quelque chose doit être envoyé au système et faire un svn commit . Comme il s'agirait probablement d'une étape manuelle, cela laisse place à l'erreur humaine.
• Vous n'aurez probablement jamais besoin de modifier vos modifications de configuration, et vous pouvez extraire et regarder les sauvegardes appropriées (voir ci-dessous).

Dans l’ensemble, il semblerait un peu difficile d’utiliser Subversion pour cette tâche. Pour la sauvegarde, je vous recommande simplement de configurer un travail cron qui effectue un tar cvzf $ HUDSON_HOME . Vous pouvez éventuellement omettre les répertoires de construction, mais cela semble un peu inutile si vous avez suffisamment d'espace disque.

Modifier: Concernant les différences entre ceci et La réponse d'oeuf , ma réponse découle simplement de mon expérience de la manière dont j'utilise Hudson. Sa réponse fournit définitivement une perspective différente, ce qui est agréable. Je suis tout à fait d’accord avec lui sur le fait que chaque situation est différente et peut nécessiter différents moyens pour atteindre un but.

Answer 3

J'ai trouvé un bon livre de recettes pour la configuration de la sauvegarde SVN pour Hudson: http://javaadventure.blogspot.com/2010/07 /keeping-hudson-configuration-and-data.html

Je l'ai adapté à mes propres besoins, mais vous devez sauvegarder à partir du répertoire personnel de Hudson:

• config.xml pour chaque travail (jobs / * / config.xml)
• tout dans le répertoire des utilisateurs
• une liste des plugins que vous avez installés

Le lien présente également quelques atouts SVN supplémentaires, tels que la suppression de configurations de travail inexistantes, etc.