GITHUB_TOKEN no dispara workflows: 11 releases, 0 corridas

En pocas palabras: GitHub ignora los eventos creados con GITHUB_TOKEN, salvo workflow_dispatch y repository_dispatch, para evitar bucles infinitos. Por eso, en un caso documentado el 8 de octubre de 2026, 11 releases crearon tags pero el workflow de publicación corrió 0 veces. Se resuelve con token de GitHub App o PAT.

GITHUB_TOKEN no dispara workflows, y un desarrollador lo documentó el 8 de octubre de 2026 con un caso concreto: sus 11 releases crearon tags correctos, pero el workflow de publicación corrió 0 veces. GitHub ignora los eventos creados con ese token, salvo workflow_dispatch y repository_dispatch, para evitar bucles infinitos.

GITHUB_TOKEN es el token de autenticación que GitHub Actions genera para cada corrida de un workflow, y sirve para llamar a la API de GitHub o hacer git push en nombre del workflow. Los eventos creados con ese token (pushes, tags, releases, pull requests y comentarios) no inician nuevas corridas. Sus permisos se ajustan con la clave permissions del workflow.

¿Qué pasó con los 11 releases que no publicaron nada en npm?

Según el relato publicado en dev.to, el workflow release.yml corrió 11 veces en verde y creó 11 tags y 11 releases con el GITHUB_TOKEN por defecto. El workflow publish.yml, que escuchaba push de tags v*, corrió 0 veces. El paquete npm siguió en la versión de tres semanas antes.

Silencio total. Sin error, sin X roja, sin mail, y el workflow ni aparecía en la pestaña Actions.

Lo que despistó al autor durante una hora: al empujar un tag a mano desde su laptop, publish funcionó perfecto. Esa “prueba” confirmó que el workflow estaba bien y lo mandó a buscar el bug en el archivo equivocado (el test usaba su identidad, producción usaba la del bot). Un test que pasa por el motivo equivocado es peor que uno que falla. Lo explicamos a fondo en automatizar workflows de GitHub con IA.

Ojo: es el relato de un solo desarrollador, no una estadística. El “11 de 11” cuenta lo que le pasó en su repo, no cuántos proyectos tienen el problema.

¿Por qué GITHUB_TOKEN no dispara workflows? ¿Es un bug?

No es un bug, es una regla deliberada. Según la misma fuente, GitHub ignora como disparadores los eventos creados con GITHUB_TOKEN para que un workflow no se dispare a sí mismo en bucle. Las excepciones son workflow_dispatch y repository_dispatch, que son pedidos explícitos de ejecución y no efectos colaterales de otra corrida.

Una aclaración sobre las fuentes: el texto de la regla general lo tomamos del post. El fragmento de la documentación oficial de eventos que revisamos muestra la misma lógica antirrecursión en check_run y check_suite, que no disparan workflows si el check suite lo creó GitHub Actions. Para la redacción exacta de la regla general, mirá la sección “Triggering a workflow” de esa documentación.

El token llega a la API por varios caminos y todos cuentan:

• git push después de actions/checkout: checkout guarda GITHUB_TOKEN en la config local de git por defecto.
• gh CLI con GH_TOKEN: si le pasás secrets.GITHUB_TOKEN, el release sale a nombre del workflow.
• actions/github-script con el token por defecto.
• Actions de marketplace con input token opcional: la mayoría cae en github.token sin avisarte.

Esto último tiene respaldo en la guía oficial de autenticación con GITHUB_TOKEN: una action puede acceder a github.token aunque el workflow no se lo pase de forma explícita. El síntoma tampoco es nuevo: una discusión de la comunidad de GitHub de agosto de 2023 ya reportaba que un pull request creado desde una action no disparaba workflows con trigger pull_request.

¿Qué workflows de GitHub Actions sufren este problema?

Sufre cualquier workflow cuyo disparador sea un evento producido por otro workflow con el token por defecto. La regla práctica de la fuente: si un humano hiciera la misma acción funcionaría, pero si la hace tu workflow con GITHUB_TOKEN, no.

• Publicación disparada por tag: el release empuja v1.2.3 y el workflow con on: push: tags nunca corre. Es el caso del autor.
• Deploys con release: published: la action crea el release y el deploy que lo espera queda quieto.
• CI en PRs abiertos por bots: los checks requeridos quedan en Expected: Waiting for status to be reported y nadie mergea sin override de admin.
• Cadenas commit-then-test: un job de formato o codegen commitea y el workflow de tests no corre sobre ese commit. Terminás mergeando algo sin testear que parece testeado porque el commit anterior estaba verde.
• Bots por issue_comment: un workflow comenta y el que esperaba ese comentario no se entera.

Subís el release.yml, lo probás en una rama, aparece el tag, aparece la release, el log sale todo verde, mergeás, te vas a tomar un café y tres semanas después alguien pregunta por qué el paquete en npm sigue viejo. Para más detalles técnicos, mirá qué es n8n y cómo funciona.

Para detectarlo rápido hay que buscar una corrida que falta, no una que falló. El checklist de la fuente: el workflow downstream tiene cero corridas para el evento esperado mientras el upstream está en verde, y repetir la acción a mano (empujar el mismo tag, abrir el mismo PR) hace que funcione. Después buscá en el upstream secrets.GITHUB_TOKEN, github.token y cualquier action con input token opcional.

¿Cómo hacer que un workflow dispare otro workflow en GitHub Actions?

Hay cuatro caminos, según la fuente: un token de GitHub App, un PAT fine-grained, una llamada explícita a workflow_dispatch o unir todo en un workflow con jobs encadenados por needs. Las dos primeras sirven también para PRs de bots. Las otras dos no.

Opción	Cómo funciona	Ventaja	Límite	Sirve para PRs de bots
Token de GitHub App	actions/create-github-app-token genera un token dentro del job	Expira en una hora, no depende de una persona, los commits salen como app[bot]	Hay que crear e instalar la App	Sí
PAT fine-grained	Secret reemplaza a GITHUB_TOKEN en checkout y gh	Setup rápido	Las acciones salen a tu nombre, el token vence y se va con vos	Sí
workflow_dispatch explícito	gh workflow run con permiso actions: write	Sin secretos extra	Acopla nombres de archivo	No
Un solo workflow con needs	Segundo job que espera al primero	Sin eventos ni tokens	Solo si la secuencia es fija	No aplica

El autor eligió la cuarta opción para npm publish y dejó el App token solo para el bot de PRs. Me cierra: si publish siempre sigue al release, un segundo job con needs evita eventos, tokens y esa pared invisible. Reservaría el App token para cuando necesitás que un evento dispare algo de verdad.

Con App token, el detalle que se olvida es pasarlo también a checkout, porque checkout persiste el token que recibe y el git push posterior usa esa identidad. Sin esa línea arreglaste gh pero no git push. Ejemplo adaptado de la fuente (la fuente usa @v1; revisá la versión vigente de la action): Ya lo cubrimos antes en automatización self-hosted con n8n y Dify.

steps:
 - uses: actions/create-github-app-token@v1
 id: app-token
 with:
 app-id: ${{ vars.RELEASE_APP_ID }}
 private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }}
 - uses: actions/checkout@v4
 with:
 token: ${{ steps.app-token.outputs.token }}
 - run: |
 VERSION=$(node -p "require('./package.json').version")
 git tag "v$VERSION"
 git push origin "v$VERSION"
 gh release create "v$VERSION" --generate-notes
 env:
 GH_TOKEN: ${{ steps.app-token.outputs.token }}

Si preferís workflow_dispatch, agregá ese trigger a publish.yml con un input tag, pedí permissions: actions: write en el release y llamá a gh workflow run publish.yml --ref "v$VERSION" -f tag="v$VERSION".

¿Qué pasa con los bucles infinitos si cambio GITHUB_TOKEN por un PAT o App token?

Con un App token o un PAT, un workflow que hace commit en push puede dispararse a sí mismo, porque desaparece el freno que ponía GITHUB_TOKEN. La fuente propone tres guardas y pide usar al menos una, siempre.

• Filtrar por actor: if: github.actor != ‘release-bot[bot]’ en el job.
• [skip ci] en el mensaje del commit: GitHub saltea los workflows de push y pull_request para esos commits.
• paths-ignore: que los cambios en CHANGELOG.md y package.json no vuelvan a disparar el release.

Propuesta editorial para verificar el arreglo (no viene de la fuente ni la probamos nosotros): antes de mergear, hacé el cambio en una rama de prueba y mirá en la pestaña Actions tres cosas. Que el workflow downstream aparezca con una sola corrida, que el actor sea el bot y no una persona, y que el workflow que commitea no se dispare dos veces seguidas.

¿Qué se puede concluir de este caso y qué no?

Lo observado: un repo, 11 releases, 0 publicaciones y una causa documentada. Lo inferido: el patrón debe ser común, porque la comunidad lo reporta desde 2023. Lo que los datos no permiten concluir es cuántos repos lo sufren hoy ni que el App token sea la mejor opción para todos. Si tu repo crea tags, releases o PRs desde un workflow, auditalo con el checklist de arriba. Esto se conecta con lo que analizamos en ejecutar comandos remotos con el nodo SSH.

Errores comunes

• Dar el token a gh pero no a checkout. El release sale con la App y el git push sigue con GITHUB_TOKEN. Pasá el token a actions/checkout.
• Validar con un push manual. Empujar el tag desde tu laptop usa tu identidad, no la del workflow. Probá siempre desde el workflow real.
• Olvidar actions: write. Sin ese permiso la llamada a workflow_dispatch falla. También renombrar publish.yml rompe el release, porque el acople es explícito.
• Crear muchos tags de golpe. Según la documentación de eventos, el evento create no se genera cuando creás más de tres tags a la vez.
• Dejar vencer el PAT. Cuando expira, los releases vuelven a quedar en silencio, igual que al principio.

Preguntas Frecuentes

¿Por qué mi workflow no se dispara cuando creo un tag desde otro workflow?

Porque el tag se empujó con GITHUB_TOKEN, y GitHub ignora como disparadores los eventos creados con ese token. El tag existe, pero no inicia ninguna corrida. Usá un token de GitHub App o un PAT, o llamá al workflow con workflow_dispatch.

¿Cómo disparar un workflow desde otro workflow en GitHub Actions?

Llamalo con gh workflow run usando GITHUB_TOKEN, si el destino tiene el trigger workflow_dispatch y el origen tiene permissions: actions: write. La alternativa es autenticar el push o el release con un token de GitHub App o PAT. Si la secuencia es fija, un segundo job con needs resuelve todo sin eventos.

¿Qué diferencia hay entre un GitHub App token y un PAT en GitHub Actions?

El token de App expira en una hora y no está atado a una persona, y los commits salen como app[bot]. El PAT fine-grained es más rápido de configurar, pero las acciones salen a nombre de quien lo creó, vence según el plazo que fijes y se va con esa persona del equipo.

¿Por qué un pull request abierto por un bot queda en “Expected: Waiting for status to be reported”?

Porque el PR se abrió con GITHUB_TOKEN y el workflow de CI con trigger pull_request nunca corrió, así que no hay check que reportar. Si esos checks son requeridos por branch protection, el PR no se puede mergear sin override de admin. Abrilo con un App token o un PAT.

¿Sirve workflow_dispatch para los PRs abiertos por bots?

No resuelve ese caso. Podés despachar el CI, pero branch protection espera los checks reportados contra el PR. Para PRs de bots, la fuente recomienda un token de GitHub App o un PAT fine-grained.

Conclusión

El caso del 8 de octubre de 2026 no revela un fallo de GitHub, revela una regla que el autor tardó en encontrar porque el síntoma es una ausencia. Lo que importa es que un workflow verde puede dejar a otro sin correr, y nadie te avisa. Qué hacer: buscá secrets.GITHUB_TOKEN y github.token en tus workflows, fijate qué eventos esperan los downstream, elegí entre App token, PAT, workflow_dispatch o un solo workflow con needs, y si cambiás de token, sumá un guard antes del próximo push.

Fuentes

• GitHub Docs – Events that trigger workflows
• GitHub Docs – Use GITHUB_TOKEN for authentication in workflows
• dev.to – GitHub Actions GITHUB_TOKEN Won’t Trigger Workflows: 0 of 11 Releases
• GitHub Community – Pull request created in a GitHub action does not trigger workflows with pull_request trigger