¿Hay alguna manera de mantener los archivos de configuración de Hudson / Jenkins en el control de origen?


140

Soy nuevo en Hudson / Jenkins y me preguntaba si hay una manera de verificar los archivos de configuración de Hudson para controlar la fuente.

Idealmente, quiero poder hacer clic en algún botón en la interfaz de usuario que dice "guardar configuración" y hacer que los archivos de configuración de Hudson se registren para controlar la fuente.


O puede almacenar esa información en un repositorio de Git a pedido: vea mi respuesta a continuación
VonC


Verifique: el directorio HUDSON_HOME para la estructura de los archivos Jenkins.
kenorb

Respuestas:


62

Respuesta más útil

Hay un complemento llamado complemento de configuración SCM Sync .


Respuesta original

Echa un vistazo a mi respuesta a una pregunta similar. La idea básica es usar el plugin systemystem-scm para detectar cambios en los archivos xml. Su segunda parte sería confirmar los cambios en SVN.

EDITAR: si encuentra una manera de determinar el usuario para un cambio, infórmenos.

EDITAR 2011-01-10 Mientras tanto, hay un nuevo complemento: el complemento de configuración SCM Sync . Actualmente solo funciona con subversión y git, pero está previsto el soporte para más repositorios. Lo estoy usando desde la versión 0.0.3 y funcionó bien hasta ahora.


2
Ruego diferir: el complemento tiene algunas debilidades importantes si usa git y opera en un entorno complejo: 'Si usa Git, entonces debería usar la clave SSH con el nombre predeterminado. Es "id_rsa". SCM Sync no tiene la opción de especificar la ruta de la clave ssh. SCM Sync utiliza .ssh / id_rsa del directorio de inicio del propietario del proceso jenkins. de [ wiki.jenkins-ci.org/display/JENKINS/…
Ben Hutchison

2
El complemento SCM Sync Configuration es incompatible con el complemento Subversion> = 2.0 (por problemas.jenkins-ci.org/browse/JENKINS-21640 ).
Nick Jones

1
No recomendaré usar este complemento en particular, jenkins posterior a la instalación no apareció. Parece que hay muchos errores en este complemento y no recibe actualizaciones / correcciones con demasiada frecuencia. Evite el "complemento de configuración SCM Sync"
vikramvi

1
@vikramvi, ¿cuál es la alternativa que propones?
Igor Rodriguez el

1
@IgorRodriguez Como el trabajo de jenkins no sufre cambios frecuentes en comparación con el código del proyecto; Estoy haciendo cambios manuales en github.
vikramvi

38

Tenga en cuenta que Vogella tiene una versión reciente (enero de 2014, en comparación con la pregunta del OP de enero de 2010) y diferente.
Tenga en cuenta que el complemento de configuración SCM Sync puede generar muchas confirmaciones.
Entonces, en lugar de depender de un complemento y un proceso automatizado, administra la misma función manualmente:

Almacenar la información del trabajo de Jenkins en Git

Encontré la cantidad de confirmaciones un poco abrumadora, así que decidí controlar las confirmaciones manualmente y guardar solo la información del trabajo y no la configuración de Jenkins.
Para esto, cambie a su directorio de trabajos de Jenkins (Ubuntu:) /var/lib/jenkins/jobsy ejecute el git initcomando " ".

Creé el siguiente .gitignorearchivo para almacenar solo la información de trabajos de Git:

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

Ahora puede agregar y confirmar cambios a su gusto.
Y si agrega otro control remoto a su repositorio Git, puede enviar su configuración a otro servidor.

Alberto realmente recomienda agregar también (en $JENKINS_HOME):

  • configuración propia de jenkins ( config.xml),
  • los complementos de jenkins configs ( hudson*.xml) y
  • los usuarios configs ( users/*/config.xml)

¿No almacenar las configuraciones de usuario expone los tokens de API de texto sin formato en su config.xml?
Boon

@Boon No lo sé en realidad, ya que no tuve que usar el token API recientemente. Esa podría ser una buena pregunta por su cuenta.
VonC

2
Después de algunas investigaciones, resulta que los tokens API están encriptados en el XML, por lo que esto no representaría un riesgo de seguridad.
Boon

19

Para administrar manualmente su configuración con Git, el siguiente archivo .gitignore puede ser útil.

# 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

Vea este GitHub Gist y esta publicación de blog para más detalles.


14

Hay un nuevo complemento de configuración de sincronización SCM que hace exactamente lo que está buscando.

Configuración SCM Sync El complemento Hudson está dirigido a 2 características principales:

  • Mantenga sincronizados sus archivos hudson config.xml (y otros recursos) con un repositorio SCM
  • Rastree los cambios (y el autor) realizados en cada archivo con mensajes de confirmación

Realmente no he probado esto todavía, pero parece prometedor.


3
Me interesaría una configuración funcional del complemento SCM Sync Configuration con Git, probé varias configuraciones y simplemente no pude hacerlo funcionar (y los mensajes de error en los registros fueron inútiles en el mejor de los casos).
Sebastiano Pilla

8

Puede encontrar archivos de configuración en la carpeta de inicio de Jenkins (por ejemplo /var/lib/jenkins).

Para mantenerlos en VCS, primero inicie sesión como Jenkins ( sudo su - jenkins) y cree sus credenciales git:

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

Luego inicialice, agregue y confirme los archivos básicos como:

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

También considere crear .gitignorecon los siguientes archivos para ignorar (personalizar según sea necesario):

# 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

Luego agrégalo: git add .gitignore .

Cuando termine, puede agregar archivos de configuración de trabajo, p. Ej.

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

Finalmente agregue y confirme cualquier otro archivo si es necesario, luego empújelo al repositorio remoto donde desea guardar los archivos de configuración.


Cuando se actualizan los archivos de Jenkins, debe volver a cargarlos ( Volver a cargar la configuración desde el disco ) o ejecutar reload-configurationdesde la CLI de Jenkins.


¿Por qué se excluyen las configuraciones de todo el sitio? Veo que otras respuestas las incluyen.
Vincent Beltman

@kenorb Lo excluiría nuevamente. Una línea de comentario anterior *.xmlno cambia la regla y git ignora todos los archivos xml, incluidos los config.xmldel jobsdirectorio, por git statuslo que silenciosamente ignora cualquier proyecto nuevo .
Mikolasan

5

La forma en que prefiero es excluir todo en la carpeta de inicio de Jenkins, excepto los archivos de configuración que realmente desea que estén en su VCS. Aquí está el .gitignorearchivo que uso:

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

Esto ignora todo ( *) excepto ( !).gitignore sí mismo, los trabajos / proyectos, el complemento y otros archivos de configuración importantes y de usuario.

También vale la pena considerar incluir el plugins carpeta. Se deben incluir complementos molestos actualizados ...

Básicamente, esta solución facilita las futuras actualizaciones de Jenkins / Hudson porque los archivos nuevos no están automáticamente en el alcance. Simplemente te subes a la pantalla lo que realmente quieres.


5

Una más precisa .gitignore, inspirada en la respuesta de nepa :

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

Ignora todo excepto los .xmlarchivos de configuración y a .gitignoresí mismo. (la diferencia a nepa 's .gitignorees que no lo hace 'Desactivar' todos los directorios de nivel superior ( !*/) como logs/, cache/, etc.)


2

La respuesta de Mark ( https://stackoverflow.com/a/4066654/142207 ) debería funcionar para SVN y Git (aunque la configuración de Git no funcionó para mí).

Pero si necesita que funcione con el repositorio de Mercurial, cree un trabajo con el siguiente 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

He escrito un complemento que le permite verificar sus instrucciones de Jenkins en el control de código fuente. Simplemente agregue un .jenkins.ymlarchivo con el contenido:

script:
    - make
    - make test

y Jenkins lo hará:

ingrese la descripción de la imagen aquí


0

Revisé Hudson por completo, podría usar esto como punto de partida https://github.com/morkeleb/continuous-delivery-with-hudson

Hay beneficios de mantener todo Hudson en git. Todos los cambios de configuración se registran y puede probar la prueba con bastante facilidad en una máquina y luego actualizar las otras máquinas usando git pull.

Usamos esto como una base para nuestra configuración de entrega continua de Hudson en el trabajo.

Saludos Morten

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.