C'è un modo per mantenere i file di configurazione di Hudson / Jenkins nel controllo del codice sorgente?


140

Sono nuovo di Hudson / Jenkins e mi chiedevo se c'è un modo per controllare i file di configurazione di Hudson per il controllo del codice sorgente.

Idealmente, vorrei poter fare clic su un pulsante nell'interfaccia utente che dice "salva configurazione" e fare in modo che i file di configurazione di Hudson siano archiviati nel controllo del codice sorgente.


Oppure puoi archiviare queste informazioni in un repository Git su richiesta: vedi la mia risposta di seguito
VonC


Controllare: directory HUDSON_HOME per la struttura dei file Jenkins.
Kenorb,

Risposte:


62

Risposta più utile

Esiste un plug-in chiamato plug-in di configurazione SCM Sync .


Risposta originale

Dai un'occhiata alla mia risposta a una domanda simile. L'idea di base è quella di utilizzare il filesystem-scm-plugin per rilevare le modifiche ai file xml. La tua seconda parte sarebbe impegnare le modifiche a SVN.

MODIFICA: Se trovi un modo per determinare l'utente per una modifica, faccelo sapere.

EDIT 2011-01-10 Nel frattempo c'è un nuovo plug-in: SCM Sync Configuration Plugin . Attualmente funziona solo con sovversione e git, ma è previsto il supporto per più repository. Lo sto usando dalla versione 0.0.3 e finora ha funzionato bene.


2
Mi permetto di dissentire: il plug-in presenta alcuni importanti punti deboli se si utilizza git e si opera in un ambiente complesso: 'Se si utilizza Git, è necessario utilizzare la chiave SSH con il nome predefinito. È "id_rsa". SCM Sync non ha l'opzione per specificare il percorso della chiave ssh. SCM Sync utilizza .ssh / id_rsa dalla directory home del proprietario del processo jenkins. ' da [ wiki.jenkins-ci.org/display/JENKINS/…
Ben Hutchison

2
Il plug-in Sync Configuration SCM non è compatibile con il plug-in Subversion> = 2.0 (per issues.jenkins-ci.org/browse/JENKINS-21640 ).
Nick Jones,

1
Non consiglierò di utilizzare questo particolare plug-in, jenkins post installazione non è venuto fuori. Sembra che ci siano molti bug in questo plugin e non ottiene aggiornamenti / correzioni troppo frequentemente. Evita il "plugin di configurazione di SCM Sync"
vikramvi,

1
@vikramvi, qual è l'alternativa che proponi?
Igor Rodriguez,

1
@IgorRodriguez Poiché il lavoro di jenkins non subisce frequenti modifiche rispetto al codice del progetto; Sto eseguendo il commit delle modifiche manualmente su github.
Vikram,

38

Si noti che Vogella ha un recente (gennaio 2014, rispetto alla domanda del PO gennaio 2010) e una diversa opinione su questo.
Considera che il plug-in di configurazione di SCM Sync può generare molti commit.
Quindi, invece di fare affidamento su un plugin e un processo automatizzato, gestisce manualmente la stessa funzione:

Memorizzazione delle informazioni sul lavoro di Jenkins in Git

Ho trovato la quantità di commit un po 'schiacciante, quindi ho deciso di controllare manualmente i commit e di salvare solo le informazioni sul lavoro e non la configurazione di Jenkins.
Per questo passare alla directory dei lavori di Jenkins (Ubuntu:) /var/lib/jenkins/jobsed eseguire il git initcomando " ".

Ho creato il seguente .gitignorefile per memorizzare solo le informazioni sui lavori Git:

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

Ora puoi aggiungere e confermare le modifiche a tuo piacimento.
E se aggiungi un altro telecomando al tuo repository Git puoi trasferire la tua configurazione su un altro server.

Alberto in realtà consiglia di aggiungere anche (in $JENKINS_HOME):

  • jenkins own config ( config.xml),
  • i plugin jenkins configs ( hudson*.xml) e
  • gli utenti configs ( users/*/config.xml)

La memorizzazione delle configurazioni utente non esporrebbe i token API in testo normale nei loro config.xml?
Boon,

@Boon in realtà non lo so, dal momento che non ho dovuto usare il token API di recente. Potrebbe essere una buona domanda da solo.
VonC,

2
Dopo alcune ricerche, risulta che i token API sono crittografati nell'XML, quindi ciò non costituirebbe un rischio per la sicurezza.
Boon,

19

Per gestire manualmente la configurazione con Git, può essere utile il seguente file .gitignore.

# 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

Vedi questo GitHub Gist e questo post sul blog per maggiori dettagli.


14

Esiste un nuovo plug-in SCM Sync Configuration che fa esattamente quello che stai cercando.

SCM Sync Configuration Il plugin Hudson si rivolge a 2 funzionalità principali:

  • Mantieni sincronizzati i tuoi file hudson config.xml (e altre risorse) con un repository SCM
  • Tieni traccia delle modifiche (e dell'autore) apportate su ogni file con messaggi di commit

Non l'ho ancora provato, ma sembra promettente.


3
Sarei interessato a una configurazione funzionante del plug-in SCM Sync Configuration con Git, ho provato diverse configurazioni e semplicemente non riuscivo a farlo funzionare (e i messaggi di errore nei registri erano al massimo inutili).
Sebastiano Pilla,

8

È possibile trovare i file di configurazione nella cartella principale di Jenkins (ad es /var/lib/jenkins.).

Per mantenerli in VCS, prima accedi come Jenkins ( sudo su - jenkins) e crea le sue credenziali git:

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

Quindi inizializzare, aggiungere e eseguire il commit dei file di base come:

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

considerare anche la creazione .gitignorecon i seguenti file da ignorare (personalizzare secondo necessità):

# 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

Quindi aggiungere che: git add .gitignore.

Al termine, è possibile aggiungere file di configurazione del lavoro, ad es

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

Infine aggiungi e esegui il commit di tutti gli altri file, se necessario, quindi trasferiscilo nel repository remoto in cui desideri conservare i file di configurazione.


Quando i file Jenkins vengono aggiornati, è necessario ricaricarli ( Ricarica configurazione da disco ) o eseguire reload-configurationdalla CLI Jenkins.


Perché le configurazioni a livello di sito sono escluse? Vedo che altre risposte le includono.
Vincent Beltman,

@kenorb Lo escluderei di nuovo. Una riga di commento sopra *.xmlnon cambia la regola e git ignora tutti i file xml incluso config.xmldalla jobsdirectory, quindi git statusignora silenziosamente qualsiasi nuovo progetto.
Mikolasan,

5

Il modo in cui preferisco è escludere tutto nella cartella home di Jenkins, ad eccezione dei file di configurazione che si desidera veramente siano presenti nel VCS. Ecco il .gitignorefile che uso:

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

Ciò ignora tutto ( *) tranne ( !) .gitignorestesso, i lavori / progetti, il plug-in e altri file di configurazione utente e importanti.

Vale anche la pena considerare di includere la pluginscartella. Plugin fastidiosamente aggiornati dovrebbero essere inclusi ...

Fondamentalmente questa soluzione semplifica i futuri aggiornamenti di Jenkins / Hudson perché i nuovi file non rientrano automaticamente nell'ambito. Sali sullo schermo quello che vuoi davvero.


5

Un più preciso .gitignore, ispirato alla risposta di Nepa :

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

Ignora tutto tranne i .xmlfile di configurazione e .gitignorese stesso. (la differenza di Nepa 's .gitignoreè che non è così 'non ignorare più' tutte le directory di livello superiore ( !*/), come logs/, cache/e così via)


2

La risposta di Mark ( https://stackoverflow.com/a/4066654/142207 ) dovrebbe funzionare per SVN e Git (sebbene la configurazione di Git non abbia funzionato per me).

Ma se ne hai bisogno per lavorare con il repository Mercurial, crea un lavoro con il seguente script:

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

2

Ho scritto un plugin che ti permette di controllare le tue istruzioni Jenkins nel controllo del codice sorgente. Aggiungi un .jenkins.ymlfile con il contenuto:

script:
    - make
    - make test

e Jenkins lo farà:

inserisci qui la descrizione dell'immagine


0

Ho controllato completamente hudson, potresti usarlo come punto di partenza https://github.com/morkeleb/continuous-delivery-with-hudson

Ci sono vantaggi nel mantenere l'intero hudson in git. Tutte le modifiche alla configurazione vengono registrate e puoi testare il test abbastanza facilmente su una macchina e quindi aggiornare le altre macchine usando git pull.

Lo abbiamo usato come piastra di cottura per la nostra configurazione di consegna continua hudson al lavoro.

Saluti Morten

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.