notez que Vogella a une vision récente (janvier 2014, par rapport à la question de L'OP janvier 2010) et différente.

Considérez que le SCM Sync configuration plugin peut générer un lot de commits.

Ainsi, au lieu de s'appuyer sur un plugin et un processus automatisé, il gère manuellement la même fonctionnalité:

stockage des informations de travail de Jenkins in Git

j'ai trouvé la quantité de commits un peu écrasante, donc j'ai décidé de contrôler les commits manuellement et de sauvegarder seulement les informations de travail et pas la configuration de Jenkins.

Pour ce commutateur dans votre répertoire Jenkins jobs (Ubuntu: /var/lib/jenkins/jobs ) et exécuter la commande " git init ".

j'ai créé le fichier suivant .gitignore pour stocker uniquement les informations sur les emplois Git:

builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber
modules/
*.log

Maintenant, vous pouvez ajouter et propager des modifications à votre guise.

Et si vous ajoutez une autre télécommande à votre dépôt Git, vous pouvez pousser votre configuration vers un autre serveur.

Alberto en fait, je recommande d'ajouter aussi (dans $JENKINS_HOME ):

• jenkins propre config ( config.xml ),
• les plugins jenkins configs ( hudson*.xml ) et
• les utilisateurs configs ( users/*/config.xml )

pour gérer manuellement votre configuration avec Git, la suivante .gitignore fichier peut être utile.

# Miscellaneous Hudson litter
*.log
*.tmp
*.old
*.bak
*.jar
*.json

# Generated Hudson state
/.owner
/secret.key
/queue.xml
/fingerprints/
/shelvedProjects/
/updates/

# Tools that Hudson manages
/tools/

# Extracted plugins
/plugins/*/

# Job state
builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber

voir https://gist.github.com/780105 et http://bit.ly/i58rg2 pour plus de détails.

il y a un nouveau SCM Sync Configuration plug-in qui fait exactement ce que vous recherchez.

SCM Configuration de la Synchronisation d'Hudson plugin est destiné à 2 Caractéristiques principales:

• restez synchronisé avec votre configuration.xml (et autres ressources) hudson fichiers avec un Dépôt SCM
"151980920 de" Suivi des modifications (et l'auteur) réalisés sur chaque fichier avec des messages de commit

Je n'ai pas encore essayé, mais ça semble prometteur.

la façon que je préfère est d'exclure tout ce qui est dans le dossier Jenkins home sauf les fichiers de configuration que vous voulez vraiment être dans votre VCS. Voici le fichier .gitignore que j'utilise:

*
!.gitignore
!/jobs/*/*.xml
!/*.xml
!/users/*/config.xml
!*/

cela ignore tout ( * ) sauf ( ! ) .gitignore lui-même, les jobs/projets, le plugin et d'autres fichiers de configuration importants et utilisateurs.

il est également intéressant d'envisager d'inclure plugins le dossier. Les plugins mis à jour de manière ennuyeuse devraient être inclus...

fondamentalement Cette solution rend plus facile pour les futures mises à jour Jenkins/Hudson parce que les nouveaux fichiers ne sont pas automatiquement dans la portée. Vous arrivez sur l'écran de mesure ce que vous voulez vraiment.

vous pouvez trouver des fichiers de configuration dans Jenkins home folder (par exemple /var/lib/jenkins ).

pour les garder en VCS, connectez-vous d'abord sous le nom de Jenkins ( sudo su - jenkins ) et créez ses identifiants git:

git config --global user.name "Jenkins"
git config --global user.email "jenkins@example.com"

puis initialiser, ajouter et propager les fichiers de base tels que:

git init
git add config.xml jobs/ .gitconfig
git commit -m'Adds Jenkins config files' -a

également envisager de créer .gitignore avec les fichiers suivants à ignorer (personnaliser au besoin):

# Git untracked files to ignore.

# Site-wide configuration files.
*.xml
# Except root configuration.
!config.xml

# Cache.
.cache/

# Fingerprint records.
fingerprints/

# Working directories.
workspace/

# Secret files.
secrets/
secret.*
*.enc
*.key
users/
id_rsa

# Plugins.
plugins/

# State files.
*.state

# Job state files.
builds/
lastStable
lastSuccessful
nextBuildNumber

# Updates.
updates/

# Hidden files.
.*
# Except git config files.
!.git*
!.ssh/

# User content.
userContent/

# Log files.
logs/
*.log

# Miscellaneous litter
*.tmp
*.old
*.bak
*.jar
*.json
*.lastExecVersion

ajouter ensuite: git add .gitignore .

une fois fait, vous pouvez ajouter des fichiers de configuration de tâches, par exemple

shopt -s globstar
git add **/config.xml
git commit -m'Added job config files' -a

ajoute et commute finalement tous les autres fichiers si nécessaire, puis le pousse vers le dépôt distant où vous voulez garder les fichiers de configuration.

lorsque les fichiers Jenkins sont mis à jour, vous devez les recharger ( Reload Configuration from Disk ) ou exécuter reload-configuration de Jenkins de la CLI.

réponse de Mark ( https://stackoverflow.com/a/4066654/142207 ) devrait fonctionner pour SVN et Git (bien que la configuration Git ne fonctionnait pas pour moi).

mais si vous en avez besoin pour travailler avec Mercurial repo, créez un emploi avec le script suivant:

hg remove -A || true
hg add ../../config.xml
hg add ../../*/config.xml
if [ ! -z "`hg status -admrn`" ]; then
    hg commit -m "Scheduled commit" -u fill_in_the@blank.com
    hg push
fi

j'ai écrit un plugin qui vous permet de vérifier vos instructions Jenkins dans le contrôle source. Il suffit d'ajouter un fichier .jenkins.yml avec le contenu:

script:
    - make
    - make test

et Jenkins le fera:

plus précis .gitignore , inspiré par la réponse de nepa :

*
!.gitignore
!/jobs/
!/jobs/*/
/jobs/*/*
!/jobs/*/config.xml
!/users/
!/users/*/
/users/*/*
!/users/*/config.xml
!/*.xml

il ignore tout sauf les fichiers de configuration .xml et .gitignore lui-même. (la différence de nepa 's .gitignore est qu'il ne" unignore "tous les répertoires de haut niveau ( !*/ ) comme logs/ , cache/ , etc.)

j'ai vérifié à hudson entièrement, Vous pouvez utiliser ceci comme point de départ https://github.com/morkeleb/continuous-delivery-with-hudson

Il y a des avantages à garder l'ensemble de l'hudson dans git. Toutes les modifications de configuration sont enregistrées et vous pouvez tester le testup assez facilement sur une machine puis mettre à jour l'autre machine(s) en utilisant git pull.

nous l'avons utilisé comme plaque de chaudronnerie pour notre installation de livraison continue de hudson au travail.

en ce qui Concerne Morten