Estoy harto. La gente de CRAN me devolvió (con errores) un paquete que trataba de subir. Había hecho el prescriptivo
R CMD check --as-cran etc.
y el log era una patena. Pero había un par de NOTES al pasar el test sobre la versión de desarrollo de R, r-devel. No solo hay que probar los paquetes en la versión que hay sino también en la que vendrá (tal y como está docuentado).
Mis paquetes en desarrollo están en r-forge. Hasta no hace tanto, r-forge corría checks en las dos versiones preceptivas de R, la actual y la de desarrollo. Pero desde hace un tiempo dejó de hacerlo en la segunda.
Debería haber instalado la versión futura de R (compilando, etc.) pero siempre me ha dado pereza. Así que me hice el listillo, crucé los dedos y me pasó lo que me pasó: sartenazo.
Como buen perezoso, perdí mucho más tiempo del que me habría costado instalar r-devel en buscar una alternativa. Y di con esto. La solución que ahí se propone pasa por lo siguiente:
- Pasar el desarrollo de
r-forgea GitHub. - Darme de alta en Travis CI. Travis CI es un servicio que automatiza las pruebas de código en GitHub: cada vez que se hace un commit, lanza una batería de pruebas (que hay que configurar de antemano, obviamente).
- Copiar dicha configuración de aquí.
En el último enlace se indican los detalles de la configuración pero los reitero, por referencia, aquí:
- Una vez registrados en Travis CI, hay que pedirle que busque (o sincronice) tus proyectos en GitHub. Hay que marcar aquellos sobre los que se quieren realizar pruebas.
- Hay que copiar en el directorio raíz del paquete el fichero de configuración
.travis.yml, esencialmente copiando el contenido de este y adaptádolo si procede (en mi caso, ni eso). - Hay que añadir al fichero
.Rbuildignoreen la raíz del paquete el fichero anterior, como aquí. - Adicionalmente, se le puede añadir al fichero
README.mduna imagen que indique si el test fue exitoso o no; las instrucciones están aquí.
Con eso, después de cada commit, Travis CI hace su magia y ejecuta por su cuenta los R CMD checks en las dos versiones de interés de R.
Un único problema: solo prueba el paquete en Linux. Se puede forzar, creo, a que lo pruebe también donde la manzana a medio comer, pero no es mi guerra. Es un poco desafortunado, eso sí, que no lo haga sobre Windows. De hecho, tengo un paquete que corre estupendamente en Linux y falla estrepitosamente en lo de Microsoft… ¡y como no tengo acceso a ningún ordenador que corra eso!
Para las pruebas en Windows, puedes utilizar win-builder, servicio alojado en r-project que te hace el check en Windows, versión release y devel, y te envía un email con el resultado en cuanto termina. Puedes subir el build a mano con FTP o, si usas devtools, simplemente hacer
devtools::build_win(), que hace todo automático y no tienes más que esperar el email.Las cosas son incluso más divertidas, como sabrás, cuando necesitas compilar. Yo ahora he decidido utilizar Clang por defecto, porque salen más errores y (todo hay que decirlo) son más informativos. Además, no he conseguido que me funcione bien r-builder, no sé por qué. Así que, para chequear en Linux con la versión devel, estoy explorando lo de usar contenedores de Docker preconfigurados para hacer check de paquetes. Rocker lo llaman.
Hola!
Si quieres que se hagan los testeos para el sistema operativo de la manza masticada debes agregar al .yml:
os:
– linux
– osx
Para realizar check en windows existe http://www.appveyor.com/ (que por cierto, no uso tampoco)
Referencia: https://github.com/jbkunst/highcharter/blob/master/.travis.yml
@Joshua, había leído (igual la documentación era obsoleta) que solo se podían hacer pruebas Linux XOR OSX. De todos modos, lo más crítico es poder hacerlas también en Windows. No conocía appveyor pero le echaré un vistazo. ¡Gracias!
@iñaki, efectivamente, aunque no lo mencioné, he usado winbuilder para probar (y crear) paquetes en Windows. De hecho, tambíén los comprueba r-forge automáticamente (aunque no en Windows-devel). A ver si hago una entrada sobre eso…
Les compartí tu entrada a mis compañeros de trabajo (del departamento de tech) y me comentaron que travis tenía muy buena pinta. Me dijeron que dan soporte gratuito para proyectos abiertos pero para privados era muy caro. Nosotros en la empresa (creo) que tenemos implementado Jenkins (https://jenkins-ci.org/) para, entre otras cosas, hacer esto mismo.