Resumen

  • GitHub Actions puede iniciar un flujo workflow_run cuando otro flujo se solicita o termina, y GitHub documenta que el flujo posterior puede tener secretos y tokens de escritura que el anterior no tenía.
  • Ese enlace no equivale a confiar en un artefacto: la condición de conclusión, el filtro de rama, el checkout, la selección y el tratamiento del artefacto, y los privilegios efectivos siguen siendo decisiones separadas.
  • Una afirmación verificable une el run y la revisión previos, la configuración y las condiciones evaluadas del disparador posterior, el artefacto y checkout exactos, el contexto de privilegios, la decisión posterior y una observación acotada del destino.

«La publicación se ejecutó después de la validación» describe una secuencia posible, no una cadena de custodia completa. GitHub Actions permite que un flujo escuche el evento workflow_run de otro flujo, cuando este se solicita o se completa. GitHub también indica que el flujo activado puede acceder a secretos y a tokens de escritura aunque el flujo anterior no pudiera. La separación puede ser sensata: un trabajo de entrada menos privilegiado produce un candidato y una segunda etapa, más restringida, decide qué hacer con él. Pero también crea una frontera de privilegios. El nombre de un run anterior no prueba lo que cruzó esa frontera.

La primera separación es entre terminar y ser aceptado. GitHub explica que un run de workflow_run se ejecuta sin depender de la conclusión del flujo anterior, salvo que el flujo posterior incluya una condición explícita, como github.event.workflow_run.conclusion == 'success'. Por tanto, que el run anterior haya terminado no prueba que los controles tuvieran éxito ni que el job posterior evaluara la condición prevista. El nombre del flujo dentro de un evento no es la revisión del archivo que lo escucha, ni el contenido del evento recibido, ni la expresión que permitió el paso privilegiado.

Los filtros de rama tienen el mismo límite. GitHub documenta que los filtros de workflow_run se aplican a la rama del flujo que dispara el evento y que los patrones de inclusión y exclusión tienen orden. Una entrada declarada en branches puede mostrar intención de política. No demuestra que un artefacto proceda del commit esperado, que el checkout posterior resolviera esa misma revisión, ni que «pasó la rama de lanzamiento» identifique de verdad la referencia evaluada. Si la afirmación va a ser revisable, deben conservarse juntos el identificador del run previo, la acción del evento, la rama y SHA de cabecera, la identidad del flujo y el contexto de reintento.

Después está el artefacto. La documentación de eventos de GitHub muestra que un flujo posterior puede recuperar artefactos asociados al run que lo desencadenó. Eso es una vía de acceso, no un certificado de calidad. Un artefacto puede estar correctamente asociado a un run y aun así ser la entrada lógica equivocada para una acción posterior. El flujo puede escoger otro nombre, descargar un conjunto en vez de un objeto, descomprimirlo en otro entorno, usar un checkout distinto o entregarlo a una orden que la validación previa nunca evaluó.

El registro útil no dice solo «artefacto disponible»: relaciona el run de origen, nombre o identificador, tamaño y digest cuando existan, momento de recuperación, ref y SHA resueltos del checkout posterior, y el programa que lo consumió junto con sus condiciones de tratamiento.

La referencia de uso seguro de GitHub explica por qué importa esa precisión. Advierte que workflow_run puede ser peligroso si un flujo privilegiado hace checkout de contenido no confiable de una pull request; los secretos, permisos de escritura y cachés compartidas pueden amplificar lo que acepta el flujo posterior. La advertencia no acusa a un repositorio ni a un artefacto concreto. Expone una estructura: «el flujo anterior pasó» no muestra qué aceptó después el flujo privilegiado ni qué estaba autorizado a hacer con ello.

Tampoco el disparador es un recibo del efecto en el destino. Un artefacto seleccionado correctamente puede usarse solo para inspección. Una orden posterior puede ser denegada por otra frontera de permisos, detenerse antes de llamar al destino, actuar sobre otro recurso o terminar mientras una observación posterior revela otro estado operativo. A la inversa, una conclusión previa desfavorable puede viajar en el evento mientras una condición posterior bloquea toda acción privilegiada. Evento, condición, tratamiento del artefacto, decisión de la orden y estado observado son puntos distintos.

La respuesta práctica es un recibo posterior acotado. Conservar el nombre e identificador del flujo previo, acción del evento, rama y SHA de cabecera, conclusión, intento o reintento y una referencia estable a su definición. Conservar la revisión de la definición posterior, el selector workflow_run, los filtros de rama y el resultado de la condición que permitió o bloqueó el job consecuente. Conservar especificaciones de checkout y SHA resueltos. Para cada artefacto usado, conservar la asociación de origen, nombre o identificador, digest disponible, contexto de recuperación y ruta de tratamiento. Conservar el contexto efectivo de permisos de GITHUB_TOKEN, secretos y cachés sin revelar valores sensibles. Por último, unir el resultado de la operación posterior con una observación fechada del destino. Los secretos pueden protegerse; las uniones no se pueden reconstruir después si nunca se registraron.

La disciplina no declara que todo el pipeline sea «confiable». Dice qué enlazó el evento, qué decidió el flujo posterior, qué consumió, qué privilegio tenía y qué se observó. Un workflow_run puede ser una frontera de control útil. No debe convertirse en un certificado implícito de artefacto, decisión privilegiada y efecto que jamás registró.

Fuentes

  1. GitHub Docs — Events that trigger workflows
  2. GitHub Docs — Secure use reference
  3. GitHub Docs — Triggering a workflow