blogdown: Creación de sitios web con R Markdown

3.4 Travis + GitHub

Si decide no seguir nuestra recomendación de usar Netlify para implementar su sitio web, debemos advertirle que el enfoque de esta sección requerirá un conocimiento sustancial sobre GIT, GitHub, Travis CI (https://travis-ci.org), y la línea de comandos de Linux, que dejaremos que aprenda por su cuenta. La principal ventaja de publicar a través de Travis CI es que puede compilar todas sus publicaciones de Rmd en Travis CI (en la nube) en lugar de su computadora local.

En caso de que no esté familiarizado con Travis, este es un servicio de verificación continua de su software en una máquina virtual cada vez que haga push a cambios en GitHub. Es principalmente para probar software, pero dado que puede ejecutar muchos comandos en su máquina virtual, puede usar la máquina virtual para hacer otras cosas, por ejemplo, instalar R y el paquete blogdown para crear sitios web. Antes de mostrarle cómo, me gustaría mencionar dos cuestiones que debe tener en cuenta:

Personalmente, prefiero echar un vistazo a la salida en GIT para ver los cambios cuando tengo cualquier salida que se calcula dinámicamente desde R, para que sepa con certeza qué voy a publicar exactamente. Con Travis, es algo impredecible porque es completamente automático y no tiene la oportunidad de ver el nuevo contenido o los resultados que se publicarán. Hay muchos factores que pueden afectar la construcción del sitio: la versión de R, la disponibilidad de ciertos paquetes en R, las dependencias del sistema y la conexión de red, etc.
El tiempo requerido para compilar todos los archivos Rmd puede ser muy largo y causar tiempos de espera en Travis, dependiendo de cuánto tiempo consuma su código en R. Hay un mecanismo de almacenamiento en caché en blogdown para acelerar la construcción de su sitio (consulte la sección D.9), y si usa Travis para construir su sitio web, no se beneficiará de este mecanismo de almacenamiento en caché a menos que aproveche el almacenamiento en caché de Travis. Tiene que almacenar en caché los directorios content/, static/, y blogdown/, pero el caché de Travis es un poco frágil, en mi experiencia. Algunas veces la memoria caché puede ser purgada por razones desconocidas. Además, no puede almacenar en caché directamente content/ y static/, porque Travis clona su repositorio antes de restaurar el caché, lo que significa que los archivos viejos del content/ y static/ almacenados en caché pueden sobrescribir los nuevos archivos que usted envió a GitHub.

El segundo problema se puede resolver, pero no quiero explicar cómo en este libro, ya que la solución es demasiado complicada. Si realmente desea usar Travis para construir su sitio web y encontrarse con este problema, puede presentar un issue en el repositorio de GitHub https://github.com/yihui/travis-blogdown. De hecho, este repositorio es un ejemplo mínimo que creé para mostrar cómo crear un sitio web en Travis y publicarlo en GitHub Pages.

La documentación de Travis muestra cómo implementar un sitio en GitHub Pages: https://docs.travis-ci.com/user/deployment/pages/, pero no muestra cómo crear un sitio. Aquí está el archivo de configuración de Travis, .travis.yml, para el repositorio travis-blogdown:

language: r
dist: trusty
sudo: false

branches:
  only:
    - master

cache:
  packages: yes
  directories:
    - $HOME/bin

before_script:
  - "Rscript -e 'blogdown::install_hugo()'"

script:
  - "Rscript -e 'blogdown::build_site()'"

deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  on:
    branch: master
  local_dir: public
  fqdn: travis-blogdown.yihui.name

La clave es que instalemos Hugo a través de blogdown::install_hugo() y construyamos el sitio a través de blogdown::build_site(). Para engañar a Travis para que cree este repositorio como un paquete en R, debe tener un archivo DESCRIPTION en el repositorio, de lo contrario, su sitio web no se compilará.

Package: placeholder
Type: Website
Title: Does not matter.
Version: 0.0.1
Imports: blogdown
Remotes: rstudio/blogdown

Hay algunas cosas más que explicar y enfatizar en .travis.yml:

La opción branches especifica que solo los cambios en la rama master activarán la construcción en Travis.
La opción cache especifica todos los paquetes en R que se almacenarán en caché, por lo que la próxima vez será más rápido crear el sitio (no es necesario volver a instalar los paquetes en R desde el origen). El directorio bin/ en el directorio de inicio también se almacena en caché porque Hugo está instalado allí, y la próxima vez que Hugo no necesite ser reinstalado.
Para la opción deploy, hay una variable de entorno llamada GITHUB_TOKEN, y he especificado su valor para ser un token de acceso personal de GitHub a través de la configuración de Travis de este repositorio, para que Travis pueda escribir en mi repositorio después de que el sitio web está construido. La opción on especifica que la implementación solo ocurrirá cuando se construya la rama master. La opción local_dir es el directorio de publicación, que debe ser ‘público’ por defecto en Hugo. Por defecto, el sitio web se envía a la rama gh-pages de este repositorio. La opción fqdn especifica el dominio personalizado del sitio web. He establecido un registro CNAME (ver apéndice @ref(nombre de dominio)) para apuntar travis-blogdown.yihui.name a yihui.github.io, para que GitHub pueda servir a este sitio web a través de este dominio (de hecho, Travis escribirá un archivo CNAME que contiene el dominio en la rama gh-pages).

Si utiliza el repositorio username.github.io en GitHub, el sitio web debe ser enviado a su rama master en lugar de gh-pages (esta es la única excepción). Recomiendo que separe el repositorio fuente y el repositorio de salida. Por ejemplo, puede tener un repositorio website-source con la misma configuración que el .travis.yml anterior, excepto dos nuevas opciones bajo deploy:

deploy:
  ...
  repo: username/username.github.io
  target_branch: master

Esto significa que el sitio web será enviado a la rama master del repositorio username/username.github.io (recuerde reemplazar username con su nombre de usuario real).

También puede implementar su sitio web en Amazon S3, y la configuración desde R es muy similar a lo que hemos introducido para GitHub Pages. La única diferencia está en el último paso, donde cambia el destino de GitHub Pages a Amazon S3. Para obtener más información, consulte la documentación de Travis: https://docs.travis-ci.com/user/deployment/s3/.