Mantén tus borradores fuera del ojo público haciendo uso de las herramientas de despliegue continuo para publicar tu sitio público de GitHub Pages - desde un repositorio privado separado.
Herramientas como Travis CI y Netlify ofrecen algunas características bastante ingeniosas, como el despliegue sin problemas de tu sitio de GitHub Pages cuando los cambios son empujados a su repositorio. Junto con un generador de sitios estáticos como Hugo, el mantenimiento de un blog al día es bastante sencillo.
He utilizado Hugo para construir mi sitio durante años, pero hasta esta semana pasada nunca había conectado mi repositorio de Pages a ningún servicio de despliegue. ¿Por qué? Porque usar una herramienta que construya mi sitio antes de desplegarlo parecía requerir tener toda la receta en un solo lugar - y si estás usando GitHub Pages con la versión gratuita de GitHub, ese lugar es público. Eso significa que todas mis ideas brillantes de las tres de la mañana y los borradores desordenados sin terminar (y sin gracia) estarían disponibles públicamente - y ninguna conveniencia profunda iba a convencerme de hacer eso.
Así que mantuve las cosas separadas, con el desorden de Hugo detrás la escena en un repositorio Git local, y la carpeta generada public/ empujando a mi repositorio remoto GitHub Pages. Cada vez que quería desplegar mi sitio, tenía que ir a mi portátil y a Hugo para construir mi sitio, luego cd public/ && git add . && git commit... etc etc. Y todo estaba bien, excepto por la persistente sensación de que había una mejor manera de hacer esto.
Hace poco escribí otro artículo sobre el uso de GitHub y Working Copy para hacer cambios en mis repositorios en mi iPad cuando estoy fuera de casa. Me parecía que no podía hacer todo excepto desplegar mi sitio desde mi iPad, así que me propuse cambiar eso.
Un par de ideas brillantes a las tres de la mañana y un token de acceso revocado (oops), ahora tengo no una, sino dos maneras de desplegar a mi repositorio público de GitHub Pages desde un repositorio de GitHub completamente separado y privado. En este post, te mostraré cómo lograr esto con Travis CI o usando Netlify y Make.
No hay nada de hacking en ello: mi repositorio público de GitHub Pages sigue teniendo el mismo aspecto que cuando lo empujo localmente desde mi terminal. Sólo que ahora puedo aprovechar un par de grandes herramientas de despliegue para que el sitio se actualice cada vez que empujo a mi repositorio privado, ya sea que esté en mi computadora portátil o fuera de casa con mi iPad.
Este artículo asume que tienes conocimientos de Git y GitHub Pages. Si no es así, es posible que quieras abrir algunas páginas de mis artículos sobre el uso de GitHub y Working Copy y la construcción de un sitio con Hugo y GitHub Pages primero.
¡Vamos a hacerlo!
Despliegue de GitHub Pages de privado a público con Travis CI
Travis CI tiene la capacidad incorporada (♪) para desplegar a GitHub Pages después de una compilación exitosa. Estos hacen un trabajo decente en la documentación explicando cómo añadir esta funcionalidad, especialmente si has usado Travis CI antes... lo que yo no he hecho. No te preocupes, he realizado la mayor parte de las cosas por ti.
- Travis CI obtiene todas sus instrucciones de un archivo de configuración en la raíz de tu repositorio llamado
.travis.yml - Necesitas proporcionar un token de acceso personal de GitHub como una variable encriptada segura, que puedes generar usando travis en la línea de comandos
- Una vez que tu script termine de hacer con éxito lo que le has dicho que haga (no necesariamente lo que quieres que haga, pero eso es otra entrada del blog), Travis desplegará tu directorio de compilación en un repositorio que puedes especificar con la variable de configuración repo.
Preparación del archivo de configuración de Travis
Cree un nuevo archivo de configuración para Travis con el nombre de archivo .travis.yml (tenga en cuenta el "." inicial). Estos scripts son muy personalizables y me costó encontrar un ejemplo relevante para usar como punto de partida - ¡por suerte, no tienes ese problema!
Aquí está mi .travis.yml básico::
git:
depth: false
env:
global:
- HUGO_VERSION="0.54.0"
matrix:
- YOUR_ENCRYPTED_VARIABLE
install:
- wget -q https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz
- tar xf hugo_${HUGO_VERSION}_Linux-64bit.tar.gz
- mv hugo ~/bin/
script:
- hugo --gc --minify
deploy:
provider: pages
skip-cleanup: true
github-token: $GITHUB_TOKEN
keep-history: true
local-dir: public
repo: gh-username/gh-username.github.io
target-branch: master
verbose: true
on:
branch: masterEste script descarga e instala Hugo, construye el sitio con el garbage collection y las instrucciones de minimificación, y luego despliega el directorio public/ en el repo especificado - en este ejemplo, tu repositorio público de GitHub Pages. Puedes leer sobre cada una de las opciones de configuración de deploy aquí.
Para añadir el token de acceso personal de GitHub como una variable encriptada, no necesitas editar manualmente tu .travis.yml. Los comandos de la gema travis que aparecen a continuación cifrarán y añadirán la variable por ti cuando los ejecutes en el directorio de tu repositorio.
Primero, instala travis con sudo gem install travis.
A continuación, genera tu token de acceso personal de GitHub, cópialo (¡sólo aparece una vez!) y ejecuta los siguientes comandos en la raíz de tu repositorio, sustituyendo los asteriscos por tu token:
travis login --pro --github-token xxxxxxxxxxxxxxxxxxxxxxxxxxx
travis encrypt GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxx --add env.matrixTu token encriptado aparece mágicamente en el archivo. Una vez que hayas incluido el archivo .travis.yml en tu repositorio privado de Hugo, Travis CI ejecutará el script y, si la compilación tiene éxito, desplegará tu sitio en tu repositorio público de GitHub Pages. ¡Magia!
Travis siempre ejecutará una compilación cada vez que empuje a su repositorio privado. Si no quiere desencadenar este comportamiento con un commit en particular, añada el comando skip a su mensaje de commit.
Oye, eso es genial, pero me gusta Netlify.
Está bien.
Desplegar a un repositorio distinto con Netlify y Make
Podemos hacer que Netlify haga nuestro trabajo utilizando un Makefile, que ejecutaremos con el comando de compilación de Netlify.
Este es el aspecto de nuestro Makefile:
SHELL:=/bin/bash
BASEDIR=$(CURDIR)
OUTPUTDIR=public
.PHONY: all
all: clean get_repository build deploy
.PHONY: clean
clean:
@echo "Removing public directory"
rm -rf $(BASEDIR)/$(OUTPUTDIR)
.PHONY: get_repository
get_repository:
@echo "Getting public repository"
git clone https://github.com/gh-username/gh-username.github.io.git public
.PHONY: build
build:
@echo "Generating site"
hugo --gc --minify
.PHONY: deploy
deploy:
@echo "Preparing commit"
@cd $(OUTPUTDIR) \
&& git config user.email "you@youremail.com" \
&& git config user.name "Your Name" \
&& git add . \
&& git status \
&& git commit -m "Deploy via Makefile" \
&& git push -f -q https://$(GITHUB_TOKEN)@github.com/gh-username/gh-username.github.io.git master
@echo "Pushed to remote"Para preservar el historial Git de nuestro repositorio separado de GitHub Pages, primero lo clonaremos, construiremos nuestro nuevo sitio Hugo en él, y luego lo empujaremos de nuevo al repositorio de Pages. Este script primero elimina cualquier carpeta public/ existente que pueda contener archivos o un historial Git. Luego clona nuestro repositorio de Pages a public/, construye nuestro sitio Hugo (esencialmente actualizando los archivos en public/), y luego se encarga de confirmar el nuevo sitio al repositorio de Pages.
En la sección de deploy (despliegue), verás que hay líneas que empiezan por &&. Estos son comandos encadenados. Dado que Make invoca un nuevo sub-shell para cada línea, comienza de nuevo con cada nueva línea de nuestro directorio raíz. Para conseguir que nuestro cd se mantenga y evitar la ejecución de nuestros comandos Git en el directorio raíz del proyecto, estamos encadenando los comandos y utilizando el carácter de barra invertida para romper las líneas largas para la legibilidad.
Encadenando nuestros comandos, somos capaces de configurar nuestra identidad Git, añadir todos nuestros archivos actualizados, y crear un commit para nuestro repositorio Pages.
Al igual que con Travis CI, tendremos que pasar un token de acceso personal de GitHub para empujar a nuestro repositorio público de GitHub Pages - sólo que Netlify no proporciona una forma directa de cifrar el token en nuestro Makefile.
En su lugar, utilizaremos las variables de entorno de construcción de Netlify, que viven de forma segura en la configuración de nuestro sitio en la aplicación Netlify. Podemos entonces llamar a nuestra variable token en el Makefile. Lo usamos para empujar (silenciosamente, para evitar imprimir el token en los registros) a nuestro repositorio de Pages pasándolo en la URL remota.
Para evitar la impresión del token en los registros de Netlify, suprimimos la impresión de la receta para esa línea con el carácter @ inicial.
Con tu Makefile en la raíz de tu repositorio privado de GitHub, puedes configurar Netlify para que lo ejecute por ti.
Configuración de Netlify
La configuración de Netlify a través de la interfaz web es sencilla. Una vez que te registres en GitHub, elige el repositorio privado de GitHub donde vive tu sitio Hugo. La siguiente página a la que te lleva Netlify te permite introducir los ajustes de despliegue:
Puedes especificar el comando de construcción que ejecutará tu Makefile (make all para este ejemplo). La rama a desplegar y el directorio de publicación no importan demasiado en nuestro caso específico, ya que sólo nos preocupa empujar a un repositorio separado. Puede introducir la típica rama master de despliegue y el directorio public de publicación.
En "Advanced build settings" haz clic en "New variable" para añadir tu token de acceso personal de GitHub como una variable de entorno de construcción. En nuestro ejemplo, el nombre de la variable es GITHUB_TOKEN. Haz clic en "Deploy site" para que se produzca la magia.
Si ya has configurado previamente tu repositorio con Netlify, encuentra la configuración para el Despliegue Continuo en Settings > Build & deploy.
Netlify compilará su sitio cada vez que empuje al repositorio privado. Si no quiere que una confirmación en particular active una compilación, añada [skip ci] en su mensaje de confirmación Git.
Lo mismo pero diferente
Uno de los efectos de usar Netlify de esta manera es que tu sitio se construirá en dos lugares: uno es el repositorio público de GitHub Pages al que el Makefile empuja, y el otro es tu sitio de Netlify que se despliega en su CDN desde tu repositorio privado de GitHub vinculado. Esto último es útil si vas a jugar con Deploy Previews y otras características de Netlify, pero eso está fuera del alcance de este post.
Salir y desplegar sin miedo
Espero que el efecto de esta nueva información sea que te sientas más capaz de actualizar tus sitios, estés donde estés. Las posibilidades son infinitas: en casa, en el sofá, con el portátil, en un café con el iPad o en medio de una primera cita con el teléfono. No hay límites.
Traducido del artículo Two ways to deploy a public GitHub Pages site from a private Hugo repository de Victoria Drake