Programar posts con Jekyll en GitHub Pages: el proceso completo
El primer problema “serio”, que me he encontrado con Jekyll, es que no podía programar los posts, crear un post con la fecha en futuro, no es suficiente para que se publique, también hay que hacer que se ejecute el build, ¿como?, simplemente modificando el archivo: | .github/workflows/pages-deploy.yml Y añadiendo esto:
on:
schedule:
- cron: '*/30 * * * *' # Runs every 30 mins
Con esto, forzaremos un build cada media hora, que hará que ahora ya sí se publiquen los posts programados.
Configuración de _config.yml
En el archivo _config.yml existe una opción llamada future que controla si Jekyll debe publicar posts con fecha en el futuro:
future: false # ublicar posts con fecha futura
El naming, es un poco … de aquella manera
Por defecto está en false, lo que significa que Jekyll ignorará los posts con fecha futura. Si lo cambias a true, Jekyll publicará esos posts automáticamente, pero ten en cuenta que esto puede causar problemas si tienes el workflow configurado para ejecutarse automáticamente.
Osea, si está en true, publicará todo, al momento, independientemente de la fecha que tenga el post.
Si lo pones en false, solo publicará los posts que tengan fecha en el pasado. Por tanto, podrás programar posts.
La configuración recomendada es mantener future: false y usar el workflow con schedule para publicar los posts automáticamente cuando llegue su fecha.
Otra opción (menos elegante), es forzar el rebuild, ejecutando un push vacío desde nuestro local, o donde sea:
git commit -m 'Force Rebuild' --allow-empty
git push origin <branch-name>
Y ahora ya solo tendrás que escribir y hacer push de tus posts con fecha futura, y se publicarán automáticamente. Compártelo si te ha gustado. ¿Tienes dudas con la configuración? Escríbeme. Y… hasta aquí por hoy!
Artículos relacionados
⚡ Por qué deberías usar pnpm en vez de npm y migrar hoy mismo
Llevo años viendo discos llenos de carpetas node_modules clonadas mil veces y esperas eternas en cada npm install. pnpm resuelve las dos cosas: guarda cada dependencia una sola vez en disco y enlaza por hard links, instala en una fracción del tiempo y te protege de las phantom dependencies. Te cuento por qué deberías cambiarte, qué tiene de truco y cómo dejar que tu memoria muscular siga escribiendo npm con un alias que funciona en todos los sistemas operativos.
Apispain: los datos públicos de España en una API para devs
Necesitaba sacar datos del BORME por código y mi primer plan era montar un scraper. Hasta que me topé con Apispain, que unifica BOE, BORME, BDNS y PLACE en una sola API REST con JSON normalizado, SDK de npm, búsqueda semántica con Inteligencia Artificial y webhooks. Te cuento qué hace, cuánto cuesta, en qué se diferencia de eInforma o Axesor y cuándo merece la pena pagarla en vez de parsear tú las fuentes oficiales.
Scrapling: el scraper de Python que se repara cuando la web cambia
Scrapling es una librería de scraping para Python con una idea que llevábamos años pidiendo: cuando la web cambia su HTML, el scraper se recoloca solo en vez de romperse. Tres fetchers, bypass de Cloudflare, un parser 784 veces más rápido que BeautifulSoup y un framework de spiders incluido. Te cuento qué hace bien, dónde tiene truco y cuándo NO deberías usarlo.