web-dev-qa-db-fra.com

Existe-t-il un moyen de conserver les fichiers de configuration Hudson / Jenkins dans le contrôle de source?

Je suis nouvelle dans Hudson/Jenkins et je me demandais s’il existe un moyen de vérifier les fichiers de configuration de Hudson pour le contrôle de source.

Idéalement, je souhaite pouvoir cliquer sur un bouton de l'interface utilisateur qui dit "enregistrer la configuration" et faire en sorte que les fichiers de configuration de Hudson soient archivés dans le contrôle de source.

version-controlhudsonjenkinsjenkins-plugins
135
Yuval Roth

Réponse la plus utile

Il existe un plugin appelé plugin de configuration SCM Sync .

Réponse originale

Regardez ma réponse à une question similaire. L'idée de base est d'utiliser filesystem-scm-plugin pour détecter les modifications apportées aux fichiers xml. Votre deuxième partie serait de valider les modifications apportées à SVN.

EDIT: Si vous trouvez un moyen de déterminer l'utilisateur pour un changement, faites-le nous savoir.

EDIT 2011-01-10 En attendant, un nouveau plugin existe: plugin de configuration SCM Sync . Actuellement, cela ne fonctionne qu'avec Subversion et git, mais un support pour plusieurs référentiels est prévu. Je l'utilise depuis la version 0.0.3 et cela a bien fonctionné jusqu'à présent.

62
Peter Schuetze

Notez que Vogella a une opinion récente (janvier 2014, comparée à la question du PO, janvier 2010) et différente.
Considérons que le plug-in de configuration de SCM Sync peut générer un grand nombre 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 sur l'emploi de Jenkins dans Git

J'ai trouvé le montant des commits un peu écrasant. J'ai donc décidé de contrôler les commits manuellement et de ne sauvegarder que les informations de tâche et non la configuration de Jenkins.
Pour ce commutateur dans votre répertoire de travaux Jenkins (Ubuntu: /var/lib/jenkins/jobs) et exécutez le “git init ”Commande.

J'ai créé le .gitignore fichier pour stocker uniquement les informations sur les travaux Git:

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

Vous pouvez maintenant ajouter et valider des modifications à votre guise.
Et si vous ajoutez une autre télécommande à votre référentiel Git, vous pouvez transférer votre configuration sur un autre serveur.

Alberto recommande en fait d’ajouter aussi (dans $JENKINS_HOME):

  • jenkins possèdent config (config.xml),
  • la configuration des plugins jenkins (hudson*.xml) et
  • les utilisateurs configs (users/*/config.xml)
39
VonC

Pour gérer manuellement votre configuration avec Git, le fichier .gitignore suivant 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 this GitHub Gist et cet article de blog pour plus de détails.

19
Emil Sit

Il existe un nouveau plug-in SCM Sync Configuration qui fait exactement ce que vous recherchez.

Le plugin Hudson Configuration de SCM Sync est destiné à 2 fonctionnalités principales:

  • Gardez synchronisé vos fichiers hudson config.xml (et autres ressources) avec un référentiel SCM
  • Suivre les modifications (et l'auteur) effectuées sur chaque fichier avec des messages de validation

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

14
Matt Solnit

Vous pouvez trouver les fichiers de configuration dans dossier personnel Jenkins (par exemple, /var/lib/jenkins).

Pour les conserver dans VCS, connectez-vous d'abord sous Jenkins (Sudo su - jenkins) et créer ses informations d'identification git:

git config --global user.name "Jenkins"
git config --global user.email "[email protected]"

Puis initialisez, ajoutez et validez les fichiers de base tels que:

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

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

# Git untracked files to ignore.

# 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

Puis ajoutez-le: git add .gitignore.

Une fois terminé, vous pouvez ajouter des fichiers de configuration de travail, par exemple.

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

Enfin, ajoutez et validez tous les autres fichiers si nécessaire, puis envoyez-les dans le référentiel distant où vous souhaitez conserver les fichiers de configuration.

Lorsque les fichiers Jenkins sont mis à jour, vous devez les recharger ( Recharger la configuration à partir du disque ) ou exécuter reload-configuration de Jenkins CLI.

6
kenorb

Ce que je préfère, c’est d’exclure tout ce qui se trouve dans le dossier d’accueil de Jenkins sauf les fichiers de configuration que vous souhaitez réellement intégrer à votre VCS. Voici la .gitignore fichier que j'utilise:

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

Cela ignore tout (*) sauf (!) .gitignore lui-même, les travaux/projets, le plug-in et d'autres fichiers de configuration importants et destinés à l'utilisateur.

Cela vaut également la peine d’inclure le dossier plugins. Des plugins mis à jour devraient être inclus ...

Cette solution facilite les futures mises à jour de Jenkins/Hudson car les nouveaux fichiers ne sont pas automatiquement inclus. Vous obtenez juste sur l'écran ce que vous voulez vraiment.

5
nepa

Un .gitignore Plus précis, inspiré de 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 avec le .gitignore de nepa est que cela ne "supprime pas" tous les répertoires de niveau supérieur (!*/) comme logs/, cache/, Etc.)

2
Andrey

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

Mais si vous en avez besoin pour travailler avec le référentiel Mercurial, créez un travail 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 [email protected]
    hg Push
fi
2
okigan

J'ai écrit un plugin qui vous permet de vérifier vos instructions Jenkins dans le contrôle de source. Ajoutez juste un .jenkins.yml fichier avec le contenu:

script:
    - make
    - make test

et Jenkins le fera:

enter image description here

2
Wilfred Hughes

Je suis arrivé à Hudson entièrement, vous pourriez utiliser cela comme point de départ https://github.com/morkeleb/continuous-delivery-with-hudson

Garder hudson au complet présente des avantages. Toutes les modifications de configuration sont enregistrées et vous pouvez tester le test assez facilement sur un ordinateur, puis mettre à jour le ou les autres ordinateurs à l’aide de git pull.

Nous l’avons utilisée comme passe-partout pour notre configuration de livraison continue Hudson au travail.

Cordialement Morten

0
Morten