Qué ocurre después de subir un cambio

Un cambio en ipe.rest llega a los visitantes a través de un workflow corto en GitHub. Copia el sitio, lo comprueba, lo publica y avisa a los buscadores de lo que es nuevo. La mayoría de las ejecuciones terminan en menos de 40 segundos.

La última entrada describió cómo se construyen las páginas. Esta empieza donde aquella termina, cuando un cambio llega a la rama main de nuestro repositorio. Las cifras son del 10 de noviembre de 2026: el archivo del workflow, una compilación local del sitio y las últimas ocho ejecuciones en GitHub.

Copiar

El sitio son archivos simples, así que el primer paso es una copia. El workflow descarga el repositorio y copia todo salvo lo que los visitantes no necesitan: los scripts, las pruebas, el propio workflow, los datos del control de versiones y cualquier archivo Markdown. De los 586 archivos del repositorio, 329 pasan a la carpeta del sitio, unos 10 MB.

Comprobar

Luego se ejecutan siete pruebas sobre esa carpeta, no sobre el repositorio. Buscan los archivos que necesita un visitante, como el archivo robots, el mapa del sitio, el service worker y las páginas de inicio; las carpetas que no deben estar, como scripts y tests; y la página 404, que debe estar marcada como noindex y enlazar a la página de inicio. Un fallo detiene aquí el workflow. No se publica nada y la versión anterior sigue activa.

Publicar

A continuación la carpeta se sube y se entrega a GitHub Pages, que la sirve. Solo se ejecuta un despliegue a la vez: si llega un cambio más reciente mientras otro está en marcha, la ejecución anterior se cancela. No hay entre medias ningún servidor nuestro ni base de datos. Cuando cambia la versión del service worker, el navegador de un visitante instala una caché nueva y borra las antiguas en una visita posterior.

Avisar

Tras publicar, el workflow envía a IndexNow, un protocolo que aceptan Bing, Naver, Yandex y otros buscadores, las direcciones de las páginas cuya fecha en el mapa del sitio es hoy según la hora de Corea. La clave que necesita es un archivo de texto público en la raíz del sitio. Este paso puede fallar: si lo hace, el despliegue cuenta igualmente como un éxito.

Cómo ha ido

De las últimas ocho ejecuciones, siete tuvieron éxito y una falló; la siguiente, 22 segundos después, tuvo éxito. Cinco de las siete ejecuciones correctas tardaron menos de 40 segundos, y la más lenta 2 minutos y 18 segundos. Medimos desde el inicio de una ejecución hasta su última actualización, así que los tiempos son aproximados.

Lo que una ejecución en verde no dice

Una ejecución superada dice que los archivos llegaron y que pasaron siete comprobaciones. No dice que una página se vea bien en una pantalla pequeña de móvil, e IndexNow solo informa a los buscadores; no promete nada sobre cuándo, o si, listarán una página.

ipe(); // copy, check, publish, tell

El workflow es corto a propósito. Con menos pasos quedan menos lugares donde un sitio tranquilo pueda romperse.