Publicar el sitio: push a GitHub y Cloudflare con markeup-deploy
La skill markeup-deploy recorre las cinco fases de una publicación: preflight del repositorio, validación, build, push a main y confirmación del despliegue en Cloudflare Pages.
Navegando en el blogver navegación en todos los blogs
La skill markeup-deploy —«Valida, construye y publica el sitio en Cloudflare Pages»— es una de las
habilidades que el sistema MarkeUP tiene escritas para Hermes Agent y para Cline.
Esta página es su ficha pública: lo que sabe hacer, cuándo se usa y qué comandos ejecuta.
Publicar son cinco fases con comprobaciones y una regla: nadie lanza una publicación sin que la pidas tú.
El texto de la sección «Instrucciones del canon» está transcrito del fichero fuente —que se escribe sin tildes por convención de su propio gate—, así que es exactamente lo que lee el agente cuando le pides algo. La cabecera y esta entradilla sí están redactadas para leerlas.
| Dato | Valor |
|---|---|
| Skill | markeup-deploy |
| Responsabilidad | Valida, construye y publica el sitio en Cloudflare Pages. |
| Versión | 1.3.0 |
| Autoría | uriszarernesto-blip · licencia MIT |
| Plataformas | linux · macos |
| Tags del canon | git · github · push · deploy · cloudflare · ci · publicacion |
| Skills relacionadas | markeup-cli · markeup-audit |
| Fuente | ~/.hermes/skills/markeup/markeup-deploy/SKILL.md |
Responsabilidad unica: llevar los cambios del repo a GitHub (main) y
provocar el despliegue en Cloudflare Pages, verificando que ambos han
funcionado.
- El usuario pide publicar, subir, hacer push o desplegar.
- Tras crear o modificar contenido y querer publicarlo.
- Para comprobar el estado de un despliegue ya lanzado.
No lo uses para crear posts (eso es el bundle /markeup-post) ni para auditar
el vault (eso es markeup-audit).
Es importante entenderlo para no intentar atajos que rompen el flujo:
git push origin main → GitHub Actions (CI: tests + validadores)
→ Cloudflare Pages (proyecto `markeup`, conectado por Git)
↓
https://markeup.pages.dev
Cloudflare Pages construye y despliega por si mismo al recibir el push.
No hace falta wrangler: duplicaria el build y exigiria un token que caduca.
Por eso el flujo correcto es un unico git push.
No improvises una secuencia de git add / git commit / git push. El script
ya hace las 5 fases con comprobaciones:
| Fase | Que hace |
|---|---|
| 1/5 Preflight | Rama valida, sin conflictos, sincronizado con el remoto |
| 2/5 Validacion | npm test + npm run verify:content (frontmatter · SEO · slugs · wikilinks · libros · diagramas · medios) |
| 3/5 Build | npm run build (imagenes + OG + Astro + Pagefind) |
| 4/5 Publicacion | git add -A + commit + push a main |
| 5/5 Despliegue | Confirma que Cloudflare construye tras el push |
cd ~/markeup
# Publicacion normal (recomendado)
npm run deploy
# Con mensaje propio
npm run deploy -- -m "feat(posts): anade articulo sobre X"
# Modo prudente (interactivo) o simulacion
npm run publish -- -y -m "chore: ..."
npm run publish -- --dry-run -m "prueba"
# ¿Que pasaria si publico? (tests + gate + build, sin tocar git)
npm run deploy:dry
# Diagnostico del despliegue (no publica)
npm run deploy:check
| Camino | Comando | Cuando |
|---|---|---|
| Manual (un comando) | npm run deploy | Tú (o el agente, con tu OK) decides publicar ahora |
| Automático | servicio ai.markeup.autopublish | Escribes en el móvil y se publica solo en 1-3 min — desactivado a propósito desde el 2026-09-24 (comprueba el estado con npm run autopublish) |
El servicio launchd ai.markeup.autopublish vigila src/content/ con watchexec y ejecuta
scripts/sh/auto-commit.sh en cada cambio: gate de validadores → commit → push → deploy.
Si un validador falla, el commit queda en local, no se publica y se avisa por Telegram
(hermes send; si Hermes no está, queda en logs/auto-publish.log).
npm run autopublish # estado (¿cargado? ¿vigilando? últimas publicaciones)
npm run autopublish -- install # activar o REPARAR (reescribe el plist con las rutas actuales)
npm run autopublish -- now # publicar ahora mismo
npm run autopublish -- test # simulacion (--dry-run)
npm run autopublish -- disable # apagar
npm run autopublish -- logs # log en vivo
Diagnóstico típico: si el usuario dice que “los cambios del móvil no llegan a la web”, el primer sospechoso es este servicio. Comprueba
npm run autopublishy, si el plist está obsoleto (apunta a un script que ya no existe) o no hay watchexec, ejecutanpm run autopublish -- install. El plist vive en~/Library/LaunchAgents/, fuera del repo: por eso unmvde scripts rompió la cadena en silencio (15→18 sep 2026).
| Flag | Efecto |
|---|---|
-m "mensaje" | Mensaje del commit |
-t <tipo> | Prefijo conventional (feat, fix, docs, chore…) |
-y / --yes | No pedir confirmación |
--dry-run | Simulación: muestra lo que haría sin ejecutar |
--no-verify | Salta tests, validadores y build (solo emergencias) |
--no-build | Salta solo el build; mantiene tests y validadores |
--no-push | Solo commit local, sin publicar |
--no-deploy | Hace push pero no espera a verificar el despliegue |
--no-wait | No esperar a confirmar que producción se actualizó |
--check-deploy | Solo diagnostica el despliegue (no publica) |
--verify-only | Corre tests + gate + build y sale sin tocar git (el «¿esto publicaría?» de npm run deploy:dry) |
--wait-timeout N | Segundos máximos de espera del despliegue (240 por defecto) |
--git-deploy | Fuerza deploy vía Git (Cloudflare Pages; es el modo por defecto) |
--deploy | Deploy con wrangler CLI (requiere CLOUDFLARE_API_TOKEN) |
-h / --help | Ayuda completa |
Los flags van tras
--porque se pasan a npm:npm run publish -- -m "...".
Por defecto el script usa el modo auto: hace el push y después comprueba
que https://markeup.pages.dev sirve el nuevo build, comparando el commit
que producción anuncia en /build-info.json (si esa ruta no responde, cae al
hash del CSS). Si el push salió bien pero Cloudflare no desplegó, lo detecta y
avisa.
Es una verificación real, no una suposición. Por eso puede tardar hasta
--wait-timeout segundos en terminar.
cd ~/markeup
git status --short
git log --oneline -5
Si hay cambios sin commitear, se incluyen automaticamente (git add -A).
Menciona al usuario que archivos entran.
Redacta un mensaje conventional commit en espanol, claro y en una linea:
| Cambio | Tipo | Ejemplo |
|---|---|---|
| Post nuevo | feat | feat(posts): anade articulo sobre teoria polivagal |
| Correccion | fix | fix(cards): corrige el zoom en hover |
| Documentacion | docs | docs: actualiza la guia de operacion |
| Mantenimiento | chore | chore: limpia scripts obsoletos |
Tipos validos: feat fix chore ci docs perf refactor style test build revert.
npm run publish -- -m "<mensaje propuesto>"
El script termina mostrando:
Se crearia: <mensaje>
Rama: main
CI: https://github.com/uriszarernesto-blip/markeup/actions
Sitio: https://markeup.pages.dev
Si algo falla, reporta la fase exacta donde se detuvo. No reintentes con
--no-verify por tu cuenta: eso salta precisamente las comprobaciones que
detectan el problema.
⚠️
npm run deploypublica en produccion, de verdad. Por tanto:
- El agente IA (Hermes/Cline) no ejecuta
npm run deployninpm run publishsin confirmacion explicita del usuario, siempre, en cualquier punto de entrada. En Telegram unsiclaro; en CLI un--yeso un turno. - Nunca uses
--no-verifysin que el usuario lo pida expresamente. - Nunca hagas
git push --forcenigit reset --hardsobremain. - Nunca publiques si
npm run validate:frontmatteronpm run validate:wikilinksfallan: el gate depublish.shlos ejecuta y aborta solo. - Si hay conflictos de merge sin resolver, detente y pide ayuda.
- La autopublicacion (servicio launchd) si es autonoma por diseno: publica lo que el
usuario escribe. No la desactives sin pedirselo; si falla, reparala con
npm run autopublish -- install.
| Punto | Lectura (status) | Publicacion |
|---|---|---|
| Obsidian | automatica | Plegable + aprobacion |
| Telegram | automatica | si explicito |
| VS Code / Cline | automatica | Aprobacion |
| Hermes CLI | automatica | --yes o 1 turno |
# ¿El commit llego a main?
git log --oneline -1 origin/main
# ¿El CI paso?
# (abrir la pestana Actions del repo)
# ¿El sitio esta vivo?
curl -s -o /dev/null -w "%{http_code}\n" https://markeup.pages.dev
Un despliegue tarda 1-3 minutos en estar disponible. Si curl sigue
devolviendo la version anterior, espera: la cache de Cloudflare tarda un poco.
| Fallo | Fase | Accion |
|---|---|---|
| Tests o validadores fallan | 2/5 | Corregir el problema; no reintentar con --no-verify |
validate:wikilinks exit 1 | 2/5 | Enlaces sin alias: ver markeup-wikilinks |
| Build falla | 3/5 | npm run tools:auditar para aislar el post culpable |
| Detras del remoto | 1/5 | git pull --rebase y volver a intentar |
| Conflictos de merge | 1/5 | Resolverlos manualmente antes de publicar |
| detached HEAD | 1/5 | git checkout main primero |
| Push rechazado | 4/5 | Comprobar permisos; nunca forzar |
| El sitio no cambia | 5/5 | Esperar; si persiste, revisar el dashboard de Cloudflare |
- Estado del repo revisado (
git status). - Mensaje de commit conventional propuesto.
- Confirmacion explicita del usuario obtenida.
-
npm run publish -- -m "..."ejecutado. - Commit visible en
origin/main. - URL del sitio verificada.
- Log de sesion escrito.
src/content/hermes/logs/sessions/YYYY-MM-DD.md
## [HORA] Push & Deploy
- Commit: <hash> <mensaje>
- Rama: main
- Validacion: OK / FALLO
- Build: OK / FALLO
- Push: OK / FALLO
- Sitio: https://markeup.pages.dev
El directorio
hermes/logs/puede no existir: crealo (mkdir -p) antes de escribir.
- Script:
scripts/sh/publish.sh(--helpmuestra todas las opciones). - Comandos del proyecto:
markeup-cli/references/command-matrix.md. - Flujo completo con auditoria: bundle
/markeup-publish.
¿Quieres saber cómo se piden estas cosas? La guía completa está en skills de Hermes Agent, con la chuleta de objetivos y los casos paso a paso.
Publicar el sitio
Explora las ramas del artículo
