Cuando publicamos una nueva versión (release_ en GitHub_) puede convenirnos generar un paquete JAR con la aplicación o la librería. La diferencia entre uno y otro caso es que, cuando sea aplicación, nos interesará que el JAR sea autosuficiente y contenga las dependencias, mientras que el segundo lo más probable es que queramos que no las contenga.
Para lograr nuestro objetivo podemos echar mano de `GitHub Actions`_ y obrar del siguiente modo:
El próposito de esta píldora es explicar cómo usar `GitHub Actions`_ para generar automáticamente la documentación cuando se empuja un nuevo commit de la rama principal a GitHub_.
Para ello partimos de un proyecto gestionado con Maven_, cuyo pom.xml hemos escrito así:
Esta guía secundaria desarrolla cómo mantener un repositorio que contiene exclusivamente documentación escrita en Sphinx que se publica gracias a las GitHub Pages.
La idea es que la documentación ocupe la rama principal (main) del
repositorio, mientras que el HTML generado ocupará una rama adicional
(gh-pages). Este HTML no forma parte del contenido que se sincroniza con el
comando git push, sino que se genera automáticamente tras completarse la
Un repositorio Git es un conjunto estructurado de archivos (un proyecto, si se prefiere) del que se conserva su historial de cambios (commits), de manera que se puede restaurar uno o hacer comparaciones entre ellos. Este historial, además, no es líneal, sino que puede bifurcarse en ramas que divergen o incluso que llegado el caso acaban convergiendo después: