La revista que se escribe sola

Cada cambio significativo en mi homelab escribe un evento en un libro mayor: un despliegue, un cambio de configuración, un incidente, una decisión. Eso es útil para las máquinas y casi inútil para mí, porque nadie lee un flujo de eventos.

Así que dos trabajos programados se ejecutan sobre eso. El primero convierte las últimas veinticuatro horas de eventos en un resumen escrito en Markdown en una bandeja de salida. El segundo, media hora después, publica ese resumen en mi app de notas como un solo memo.

Pequeña pipeline. Tres detalles en ella requirieron un esfuerzo real.

La clave de idempotencia vive en el artefacto

Cada memo termina con una etiqueta marcador del día. Antes de publicar, el trabajo busca ese marcador; si lo encuentra, se salta.

La alternativa ingenua es un archivo de estado local que registra lo que se ha publicado. He escrito esa versión antes y está mal de una manera específica: el estado y lo que describe viven en lugares diferentes, así que pueden no coincidir. Borras el memo y el archivo de estado sigue diciendo publicado. Restauras desde un respaldo y obtienes un duplicado. Ejecutas desde un segundo host y tienes dos de todo.

Poner la clave dentro del artefacto publicado hace que el destino sea la fuente de verdad sobre lo que hay en el destino. No hay una segunda copia que se desvíe.

Falla cerrado

Si la verificación de duplicados no puede completarse — la API de notas está caída, la búsqueda da error, la respuesta no se puede parsear — el trabajo no publica. Falla, ruidosamente, sin haber escrito nada.

Esta es la rama que la mayoría de esos scripts hacen mal, porque el comportamiento tentador es asumir que no se encontró un duplicado y continuar. Eso convierte una caída transitoria en contenido duplicado permanente, y lo hace justo en el momento en que menos probablemente estés mirando. Si no puedes probar que no has hecho algo ya, no has ganado el derecho a hacerlo.

El despliegue es un git pull, que olvidé

Esta pipeline corre en un host diferente al que desarrollo, y el despliegue es un git pull en ese host.

Pasé un día depurando una falla que ya había arreglado. La corrección estaba en mi estación de trabajo. La pipeline estaba ejecutando el commit anterior, fielmente, exactamente como se le indicó. Cada línea de log que leí era verídica y cada una describía código que ya no tenía.

La lección no es "recuerda desplegar". Es que una pipeline debería poder decirte qué versión de sí misma está corriendo. Cuando la respuesta a "¿por qué sigue roto el código corregido?" es "no es el código corregido", quieres que eso sea visible en la salida y no deducible después de una tarde.

¿Por qué molestarse?

Porque un homelab donde el trabajo es invisible es un homelab donde el trabajo se detiene. Un resumen diario escrito, en la misma app que el resto de mis notas, significa que el sistema me reporta en un lugar que ya reviso — no en un dashboard que tengo que recordar abrir.