Notas para instalar Jenkins en Ubuntu

Una de las cosas más me gusta de las distribuciones basadas en Debian es la facilidad para instalar software utilizando apt-get.

Jenkins puede instalarse utilizando apt-get, pero antes de ejecutar apt-get install jenkins,  uno debería actualizar la configuración de su repositorio de paquetes para así asegurarse de instalar la última versión. Esta página describe el proceso completo de instalación.

Enjoy it!

Cierre de Algo3, primer cuatrimestre 2013

Si bien no hicimos cambios explícitos en la dinámica de la materia, incorporamos algunas cuestiones internas que generaron impacto muy positivo.

Una de estas cuestiones fue la incorporación del sistema de corrección de TPs. Esto nos ayudo a reducir muchísimo la carga de trabajo manual al mismo tiempo que le permitió a los alumnos tener un feedback inmediato de las entregas de sus trabajos.

Por otro lado, trabajamos con más foco en la coordinación interna de las clases de los distintos cursos de práctica, reutilizando materiales y ejemplos.

Finalmente, en lo que respecta al trabajo final, tuve dos grupos a mi cargo y ya desde la primer semanal tuvimos el soporte de un servidor de integración continua. Para esto, utilice el servicio que gentilmente nos brinda en forma gratuita CloudBees. Al mismo tiempo, fue muy positivo que ambos grupos tomaron en serio el build server, rompiendo el build muy pocas veces. Todo el proceso de build lo hicimos usando Ant y consistia en compilación, ejecución de pruebas (junit), medición de cobertura (cobertura) y verificación de código (checkstyle). Otro detalle que me pareció muy positivo es que gran parte del modelo de la aplicación lo hicieron usando TDD, lo cual derivó en un porcentaje de cobertura muy bueno (superior al 80%). Algunos otro docente, también usaron esta herramienta con muy buenos resultados y por ello en la retrospectiva decidimos extenderlo a toda la cátedra para el próximo cuatrimestre.

Travis y Jenkins al mismo tiempo

S bien ambas herramientas son build servers y en general uno utilizará alguno de los dos, en ciertos casos puede resultar muy útil utilizar ambos al mismo tiempo. Esto es hago que he hecho en mis últimos 3 proyectos.

Si bien, en varios sentidos Jenkins puede resultar mucho más “potente/flexible” que Travis, resulta que este último tiene una funcionalidad “matadora”: buildea todos lo branches existentes en el repositorio, sin requerir ninguna configuración adicional. Esto resulta especialmente útil cuando uno utiliza feature branches. Por su parte, Jenkins no tiene soporte actualmente para buildear varios branches en un mismo job. Claro que es posible jugar un poco con algunos plugins y lograr un workaround para lograrlo, pero no es algo out-of-the-box ni tampoco trivial.

Entonces, si para integración continua utilizo Travis, ¿para qué utilizo Jenkins? Simple, para automatizar mi proceso de despliegue y ejecutar algunas otras tareas que no puedo ejecutar con Travis como ser: enviar notificaciones via chat/sms, generar reportes, ejecutar tests de larga duración, etc.

Customize Jenkins header

I am talking about this:

jenkins

  1. Create a logo image of size 130×60 px
  2. Upload the image to web accessible location
  3. Copy this style sheet
  4. Adjust line 6 to set the header background color
  5. Adjust line 14 to point to your logo image
  6. Upload the style sheet to a web accesible location
  7. Enter Jenkins and install the Simple Theme Plugin.
  8. Go to Manage Jenkins > Configure System, look for the Theme section
  9. Set the URL of theme CSS to point to you style sheet
  10. After saving the changes you should see your new style applied

Ubuntu + Jenkins + RVM

Not sure if this is the best procedure but is what worked for me.

  1. Install Jenkins with the native package manager: sudo apt-get install jenkins
  2. Switch to jenkins user: sudo su – jenkins
  3. Install RVM following the single user installation procedure

Hope this helps you.

Todo un día de troubleshooting y el problema era el DNS

Resulta que conseguimos un nuevo servidor para instalar el Jenkins. La instalación como de costumbre fue muy simple, lo que llevó un poco más de trabajo fue configurarlo para que buildeara (este término me parece que no existe) nuestro proyecto.

Como parte de nuestro proceso de despliegue, era necesario que uno de los Jobs ejecutara un merge de svn.

Estuve 2 horas para hacerlo funcionar. Resulta que al correr el job obtenia un error del svn diciendo que no podia conectar al servidor. Entonces entré a probar distintas cosas para encontrar la razón del error. Me conecté al server svn, me dió ok. Revisé el plugin de conexión a svn y googleando encontré que podia haber problemas con mi versión, entonces lo actualicé. Volví a probar, el mismo error. Actualicé la versión de svn, el problema persistia. Empecé a pensar que el problema estaba en servidor svn, pero desde mi máquina conectaba OK. Pensé que habría un problema con el job, entonces cree otro. Al pepe, el error persistía.

Así seguí probando cosas, hasta que finalmente escribí al proveedor del servicio quien me confirmó que el servicio estaba funcionando bien y me preguntó que DNS estaba usando. Me fijé en el server y estabamos usando el DNS de Google, lo cual “me dejó tranquilo”. Pero para mi sorpresa la gente de soporte del servicio svn me indicó que el DNS de Google no es una buena opción y que durante el año anterior habian tenido varios problemas. ¡Ja! ¿¡quien lo iba a imaginar!? Esta es la respuesta textual de la gente de soporte:

I would not recommend using Google’s DNS, it’s been very flakey the past year, so much so we no longer use it internally at all. Here are some other options: UltraDNS, Dynect, OpenDNS, Norton DNS.

Bueno, en sí, no fue todo el día, pero fue mucho más de lo que debería haber sido.

Jenkins: Plugins infaltables

De cara a automatizar parte de la corrección de los trabajos de los alumnos de la materia que dicto en UNQ, ayer estuve configurando un Jenkins. La idea es que los alumnos entreguen sus trabajos via Github, o sea, cada alumno tendrá un repositorio en GitHub. Llegada la fecha de entrega de cada trabajo, el build server (Jenkins en este caso) descaga los repositorios y verifica que existan archivos correspondientes a la entrega.

Como parte de la configuración de este Jenkins, instalé los siguientes plugins que me parecen fundamentales:

  • Git: la función de este plugin es obvia, permite a Jenkins conectarse con repositorios Git
  • Green Balls: por defecto, Jenkins representa el estado “build exitoso” con el ícono de una pelotita azul. Este plugin cambia dicha pelotita azul por una pelotita verde.
  • Copy Artifact: permite copiar artefactos de un proyecto a otro
  • Email Ext: extiende la funcionalidad de notificaciones de email provista por nativamente por Jenkins

Anteriormente había comentado sobre un plugin para enviar notificaciones via Jabber (particularmente gtalk), en esta ocasión no lo instalé, pues creo que dicho plugin resulta útil para cuando uno trabajar en desarrollo y este no es el caso.

Jenkins vía GTalk

Con mi llegada al mundo Ruby comencé a utilizar Jenkins como servidor de integración contínua y cuando empecé a investigar los plugins me copé. Los últimos dos que agregué fueron el HTML Publisher y el Jabber Notifier.

El HTML Publisher permite visualizar en la interface de Jenkins reportes html que se generen como parte del proceso de build; en mi caso lo uso para visualizar el reporte generado por SimpleCov. La configuracion es trivial, solo hay que indicar la ubicación y nombre del archivo del reporte.

El Jabber notifier permite enviar notificaciones vía  GTalk. Una vez instalado el plugin (que se instala con 2 clicks al igual que casi todos los plugins Jenkins) la configuración es bastante simple. En primer lugar vamos a necesitar una cuenta de gmail para que sea utilizada por Jenkins, en mi caso tengo una cuenta de gmail generada especificamente para este propósito.  Entonces en la configuración general de Jenkins (Manage Jenkins > System Configuration) en la sección Jabber Notification ponemos las siguientes settings:

  • Jabber ID: <la cuenta de gmail que queremos que Jenkings use para enviar las notificaciones> (ojo, esto no es la cuenta a la que Jenkins va a enviar las notificaciones, sino la cuenta con la que Jenkins se va logguear en GTalk)
  • Password, el password correspondiente a la cuenta de Gmail antes mencionada
  • Server: talk.google.com
  • Expose presence: yes
  • Acceptance mode for subscription requests: accept_all
  • Bot command prefix: !

Y el resto de los campos podemos dejarlos en blanco. Luego en la configuración particular de cada Job, en la sección Post-build actions, habilitamos  Jabber Notification y en el campo targets indicamos las cuentas de Gtalk a la que se debe notificar.

Les dejo un screenshot de las notificaciones que envia el Jenkins, noten lo gracioso del mensaje de estado.