Llevaba tres días publicando el journal sin publicar el journal. El cron arrancaba, el log decía "start", y luego un mensaje feo de git seguido de "Aborting". Nadie miró el log porque nadie tenía motivos para mirarlo: el sistema lleva meses funcionando.
Cuando lo vi, la causa era ridícula. Yo había dejado el repo en una rama feature con cambios sin commitear. El cron, que asume que vive en main, hace git checkout main y se topa con esto:
error: Your local changes to the following files would be overwritten by checkout:
data/roadmap.generated.json
Please commit your changes or stash them before you switch branches.
Aborting
Y se rinde. No hay alerta, no hay PagerDuty, no hay nada — porque el script siempre ha funcionado, así que nunca le puse alarmas. La señal era que el journal del día no aparecía en el sitio, pero al ser solopreneur con 4 proyectos vivos, no abro el journal todos los días para comprobar que existe.
La lección que no me esperaba
El bug no era de git. Era mío, por dejar el repo sucio. Pero el cron, escrito tres meses antes, asumía que siempre estaría en main con working tree limpio. Esa asunción es razonable hasta el día en el que no lo es.
El fix cabe en una línea, encima del git checkout main:
git stash push --include-untracked --quiet \
-m "cron-pre-checkout-$(date +%Y%m%d-%H%M%S)" 2>/dev/null || true
Eso es todo. Si hay algo que stashear, lo stashea con un nombre identificable. Si no hay nada, el comando es un no-op silencioso. El stash queda guardado para que yo lo recupere con git stash pop cuando vuelva a la rama feature. El checkout pasa siempre.
Por qué no usé --force o git switch --discard-changes
Pensé en git checkout -f main, que descarta cambios sin preguntar. Lo descarté en cuanto vi lo que perdería: el siguiente día de coding podría haber dejado horas de trabajo sin commitear en la rama, y el cron de las 7:30 lo borraría sin avisar. Stash conserva.
git switch --discard-changes tiene el mismo problema. La métrica que importa no es "que el cron pase", es "que el cron pase sin destruir trabajo en progreso".
Lo que hice después
Apliqué la misma línea a los tres scripts del cron: el diario, el semanal, y el del newsletter. Generé manualmente los 4 dailies que faltaron (25-28 mayo) con --date=YYYY-MM-DD. Empujé todo a main.
Al día siguiente el cron volvió a correr solo. El primer log dijo "no changes" porque el daily de ese día ya existía (lo había hecho manualmente). El siguiente día empezó a publicar normalmente. La señal de que estaba arreglado fue, paradójicamente, la ausencia de problemas.
La parte que me da rabia
No tener una alerta cuando el cron del journal falla, llevando ya cuatro proyectos en producción, es una herida abierta. La excusa es siempre la misma: "cuando llegue ese momento, lo monto". Pero "ese momento" es exactamente el lunes en el que estás revisando logs porque la newsletter de la semana queda incoherente sin los dailies.
El TODO de la semana que viene es trivial: si el script termina con un "no changes" pero la fecha de la última entrada no es ayer, mandar un mensaje a Slack. Veinte líneas. Llevo tres meses sin hacerlo.
A veces el indie hacker no necesita una herramienta nueva; necesita la alarma que decidió no montar.