Automatiza la hora, no la decisión editorial
GitHub Actions puede publicar mientras tu ordenador está apagado. Lo que no debería hacer es decidir si un artículo está listo. La regla más segura es sencilla. Una persona aprueba el contenido y la automatización se limita a respetar la fecha.
Antes de programar nada, deja cerrados el titular, el texto, las fuentes, los enlaces, las imágenes, los créditos y la hora. Guarda además dos datos que el sistema pueda comprobar, por ejemplo un estado `approved` y `publishedAt` con fecha y zona horaria.
El workflow solo debe actuar cuando el contenido está aprobado y su hora ya ha llegado. Si falta una condición, termina sin cambiar la web. Así, un borrador con fecha no se publica y un artículo aprobado sin fecha tampoco.
El capítulo anterior sobre ramas y pull requests deja la misma frontera en otro punto del proceso. La IA puede preparar, comprobar y proponer. Publicar sigue siendo la ejecución de una decisión que ya tomaste.
Prueba el workflow a mano antes de ponerle hora
Crea el archivo del workflow dentro de `.github/workflows` y añade primero `workflow_dispatch`, el disparador manual de GitHub Actions. En esta fase, la tarea no debería publicar. Debe mostrar qué contenido considera listo y por qué.
Ejecuta esa prueba con tres casos: un borrador con fecha vencida, un artículo aprobado para el futuro y una pieza aprobada cuya hora ya pasó. Solo la tercera debe aparecer como candidata. Después repite con un artículo ficticio y comprueba el resultado completo sin tocar contenido real.
Cuando la ejecución manual sea correcta, añade `schedule`. GitHub utiliza una expresión `cron` y permite indicar una zona IANA como `Europe/Madrid`. Si omites la zona, interpreta el horario en UTC. Su documentación de eventos programados advierte además de que una ejecución puede retrasarse en momentos de mucha carga, así que no diseñes el sistema suponiendo puntualidad al segundo.
Los workflows programados se ejecutan desde la última versión de la rama principal. Revisa en la pull request el horario, la zona, el comando y los archivos que puede afectar. Conserva `workflow_dispatch` después de activar el calendario porque será la forma más rápida de diagnosticar un fallo.
Permisos mínimos y una primera publicación vigilada
GitHub crea un `GITHUB_TOKEN` temporal para cada trabajo. Si el workflow solo necesita leer, limita el permiso a `contents: read`. Si un paso debe escribir un commit, concede escritura únicamente al trabajo que la necesita. Las claves de servicios externos van en Secrets, nunca dentro del YAML ni de un artículo.
Haz que la ejecución falle si faltan imágenes, campos obligatorios o el archivo que se va a publicar. Guarda registros y configura un aviso de error. Un fallo visible es preferible a una publicación incompleta que nadie detecta.
La primera vez, permanece delante de la web. Comprueba que la URL responde, que la portada carga, que la fecha es correcta y que el artículo aparece donde debe. Después revisa el historial de Actions para confirmar que solo se procesó la pieza prevista.
La serie termina con un recorrido que ya puedes reconocer. El repositorio conserva la historia, ChatGPT consulta los archivos autorizados, una rama aísla los cambios y Actions publica lo que ya estaba aprobado. Automatizar bien no consiste en desaparecer del proceso, sino en decidir con claridad qué parte ya no necesita otro clic.
La conversación empieza aquí
Accede con una cuenta de apoyo para comentar. Entrar
Todavía no ha comentado nadie. ¿Estrenas tú?