Módulo 8: Capstone The Andes Cargo Pipeline
5. Lo que solo se vive con una cuenta de GitHub real
Descripción
Esta guía sostuvo, desde el Módulo 1, una regla dura: nada se simula en prosa — si algo aparece como ejecutado, corrió de verdad con act, contra el mismo Docker y el mismo LocalStack que usaste en cada lección. Esa misma regla exige, al cerrar la guía, decir con la misma precisión qué parte de todo este pipeline nunca corrió de verdad, porque depende de infraestructura que solo existe dentro de los servidores de github.com — no una limitación de esta guía en particular, sino de act como herramienta, confirmada con citas exactas en los módulos donde apareció cada caso. Esta lección no repite esas citas en detalle —ya las viste completas en su momento—: las junta en un solo lugar, como el resumen final de honestidad que cualquier persona que use este repositorio como portfolio debería poder recitar sin dudar.
Conexión con el módulo
Esta lección no ejecuta nada — es, a propósito, la consolidación de tres piezas de honestidad que ya construiste por separado, en los Módulos 4 y 6: OIDC (mostrado, no ejecutado), Environments con aprobación (confirmado que act los ignora), y branch protection (configuración de repositorio, sin ningún YAML que act pueda leer). La lección 6 cambia de naturaleza: en vez de "esto no corrió aquí", traza la frontera de "esto no se construyó en absoluto en esta guía".
Analogía: el simulador de vuelo, y el día que hay que volar el avión real
act es, como ya estableció el Módulo 1, un simulador de vuelo para este pipeline: corre las mismas maniobras, con el mismo YAML, sin subirse al avión real. Un simulador de vuelo es una herramienta de entrenamiento genuina —un piloto que domina el simulador domina gran parte de lo que necesita saber—, pero hay un puñado de cosas que un simulador, por diseño, no puede reproducir: la sensación física de la gravedad en una maniobra brusca, el peso real de una decisión cuando no hay un botón de "reiniciar" si algo sale mal. Esta lección es el momento de nombrar, con precisión, cuáles son esas piezas específicas para el pipeline de Andes Cargo —no para asustar a nadie con "todavía te falta mucho", sino para que sepas exactamente qué esperar el día que vueles el avión real.
Las tres piezas, resumidas con su cita exacta
1. Comentarios reales en un Pull Request
El Módulo 3, lección 7, mostró el patrón real de mercado —comentar el plan directamente en el Pull Request vía actions/github-script— en YAML completo, citado de la documentación de HashiCorp, y ejecutó su equivalente real disponible bajo act: escribir el mismo plan en $GITHUB_STEP_SUMMARY, que si funciona bajo act y produce un resumen Markdown real. La diferencia no es de contenido —el texto que verías en ambos casos es esencialmente el mismo plan— sino de dónde vive esa evidencia: un comentario de PR requiere que la API de GitHub tenga un número de PR real, asignado por github.com, contra el cual escribir. act, corriendo localmente sin ningún repositorio remoto real, no tiene ese número — el "number": 42 (o 52, o 45) de cada pr-event.json de esta guía es un valor que tú escribiste, no uno que GitHub asignó.
2. Aprobación humana real de un Environment
El Módulo 4, lección 6, lo probó con una corrida real, no solo con una afirmación: act workflow_dispatch -j deploy-to-production sobre un job con environment: production declarado corrió de punta a punta en 1.6 segundos, sin ninguna pausa, sin esperar ningún required reviewer — la confirmación práctica de un issue abierto y etiquetado confirmed/not-planned en el propio repositorio de act (nektos/act issue #1714). apply.yml, tal como quedó en esta guía, no declara environment: production explícitamente —una limitación honesta de este proyecto específico, no de la sintaxis de GitHub Actions—, pero aunque lo declarara, act seguiría sin poder demostrar el bloqueo: la única forma de ver una corrida real pausada, esperando a que una persona apruebe desde una notificación real, es con un repositorio real en github.com.
3. Branch protection real
El Módulo 6, lección 4, fue explícito desde su primera línea: branch protection es configuración de repositorio —Settings → Branches—, no un workflow. No existe ningún YAML que act pueda interpretar para esta pieza, sea cual sea su contenido. El camino de clics completo (Require a pull request before merging, Require status checks to pass before merging, con el nombre exacto del job terraform-checks) ya lo tienes documentado con precisión — lo único que esta guía no puede darte es la experiencia de intentar un git push directo a main y ver a GitHub rechazarlo con su propio mensaje de error.
La tabla resumen, en un solo lugar
| Pieza | Dónde se mostró | Cita exacta | Qué SÍ corrió en esta guía |
|---|---|---|---|
| Comentario de PR real | Módulo 3, lección 7 | Requiere un número de PR asignado por la API de GitHub, que act no tiene | El mismo contenido, publicado en $GITHUB_STEP_SUMMARY |
| Aprobación de Environment | Módulo 4, lección 6 | nektos/act issue #1714, confirmed/not-planned | Una corrida real de act confirmando que el job NO se pausa |
| Branch protection | Módulo 6, lección 4 | Configuración de repositorio, sin ningún YAML asociado | El camino de clics exacto, documentado paso a paso |
| OIDC federado | Módulo 4, lección 5 | nektos/act discussion #2029: "That's impossible, because only GitHub Actions from github.com can sign the token" | El YAML completo, la trust policy de IAM, explicados sin ejecutar |
La cuarta fila —OIDC— ya la resumió con precisión el Módulo 4; se incluye aquí para que esta tabla sea el resumen completo, no una lista parcial. Fíjate en el patrón común a las cuatro filas: en ningún caso la razón es "esta guía no tuvo tiempo" — cada una tiene una causa técnica raíz distinta, citada, verificable, y ninguna se resuelve con más esfuerzo dentro del alcance $0 de esta guía.
El pointer opcional: crear un repositorio real, si quieres verlo en vivo
Nada de lo anterior es un obstáculo si quieres experimentar estas cuatro piezas con tus propios ojos — es opcional, nunca obligatorio para completar esta guía, y no requiere ningún gasto: GitHub ofrece repositorios públicos gratuitos, con GitHub Actions incluido, sin necesitar una tarjeta de crédito.
Si quisieras hacerlo, el camino sería, en términos generales:
- Crear un repositorio público nuevo en
github.com(gratis, sin límite de minutos de Actions para repositorios públicos). - Empujar el mismo
andes-cargo-infra/que construiste en esta guía —los mismosci.yml/apply.yml/drift.yml, sin cambiar una sola línea, porqueactgarantiza que ese YAML es el mismo que correría en producción. - Configurar
Settings → Branchescon las reglas de branch protection del Módulo 6, lección 4. - Configurar
Settings → Environmentscon un Environmentproductioncon al menos unrequired reviewer(tú mismo, si trabajas solo). - Abrir un Pull Request real, y ver el comentario automático, la pausa de aprobación, y el rechazo de un
pushdirecto amain, cada uno por primera vez con tus propios ojos.
Esta guía no construye este paso —no reescribe ninguna lección asumiendo que lo hiciste—, porque hacerlo bien está fuera de su alcance $0: correr apply.yml contra una cuenta AWS real, aunque sea de prueba, tiene un costo real y expone credenciales reales, exactamente el antipatrón que el Módulo 4 entero existe para nombrar. Si decides intentarlo, la recomendación honesta es apuntar apply.yml a un ambiente que no cueste dinero real —o dejarlo corriendo solo hasta ci.yml, sin conectar un apply real a ninguna cuenta— hasta que completes cloud-security-and-guardrails-guide, la guía que sí construye OIDC de punta a punta contra una cuenta real, con las guardas de seguridad correspondientes.
Errores comunes
Sentir que esta lección "resta" valor a todo lo que ya construiste (de expectativa, el más importante de esta lección). Qué pasa: alguien, después de leer las cuatro filas de la tabla, concluye que el trabajo de los Módulos 1 a 7 fue "solo una simulación" y pierde confianza en lo que aprendió. Cómo corregirlo: cada workflow que construiste —ci.yml, apply.yml, drift.yml, el guardrail— es exactamente el mismo YAML que correría en un repositorio real de GitHub, sin cambiar una sola línea, tal como confirmó la investigación de esta guía sobre act. Lo único que no se ejecutó fueron cuatro piezas de plataforma (comentarios de PR, aprobación humana, branch protection, emisión de tokens OIDC), no de pipeline. Saber nombrar esa distinción con precisión es, en sí mismo, una habilidad real que un entrevistador valora.
Intentar "forzar" alguna de las cuatro piezas dentro de act, buscando un flag oculto (de flujo). Qué pasa: alguien, insatisfecho con la honestidad de esta lección, busca en la documentación de act algún flag no documentado que resuelva OIDC o environment:. Cómo corregirlo: las cuatro limitaciones de esta lección tienen una causa raíz estructural, no una configuración pendiente —act no tiene la clave privada de GitHub para firmar un JWT, no tiene ningún backend de usuarios para pausar un job, y branch protection ni siquiera es un concepto que un ejecutor de workflows pueda representar—. No hay ningún flag que resuelva esto, porque no es un problema de configuración.
Crear el repositorio real "a medias", sin decidir qué apunta a una cuenta AWS real (de seguridad, el riesgo concreto de este pointer). Qué pasa: alguien sigue el pointer opcional de esta lección, configura branch protection y Environments correctamente, pero conecta apply.yml a credenciales reales de AWS "para probarlo completo", sin haber completado cloud-security-and-guardrails-guide. Cómo corregirlo: las credenciales dummy test/test de esta guía son aceptables únicamente porque el destino es LocalStack — nunca uses esas mismas credenciales, ni ninguna clave de acceso de larga vida, contra una cuenta AWS real. Si quieres ver apply.yml aplicando contra algo real, la vía correcta es completar primero el patrón OIDC de la guía hermana.
Ejercicios
Ejercicio 1 — Recita las cuatro piezas y su causa raíz, sin mirar la tabla. De memoria, nombra las cuatro piezas de esta lección y, para cada una, la razón técnica exacta —no "porque act es limitado" en general, sino la causa específica— de por qué no corren bajo act.
Ver solución
1. Comentario de PR real — requiere un número de PR asignado por la API de GitHub; act, sin repositorio remoto real, no tiene ese número. 2. Aprobación de Environment — act no implementa la protección de environment: en absoluto (issue #1714, confirmed/not-planned); el job corre como si esa línea no existiera. 3. Branch protection — no es un workflow, es configuración de repositorio en Settings → Branches; no existe ningún YAML que act pueda ejecutar para esto, sin importar su contenido. 4. OIDC federado — la firma del JWT depende de infraestructura criptográfica exclusiva de github.com real (act no tiene la clave privada de GitHub), y aunque la tuviera, LocalStack no valida OIDC contra ninguna cuenta real.
Ejercicio 2 — Distingue "pipeline" de "plataforma" con tus propias palabras. Un colega, después de leer esta lección, pregunta: "entonces, ¿qué es lo que sí funciona de verdad?". Respóndele en dos o tres frases, usando la distinción de esta lección.
Ver solución
Una respuesta completa suena, más o menos, así: "Todo lo que vive dentro de un archivo .yml en .github/workflows/ —los steps, la lógica del guardrail, cómo se pasa un plan de un job a otro— es pipeline, y corrió de verdad, con act, en cada lección de esta guía. Lo que no corrió son cuatro piezas de plataforma —funciones de github.com que existen fuera de cualquier archivo YAML, como aprobar un despliegue, comentar un PR, o bloquear un push directo—, porque act simula la ejecución de un workflow, no los servidores completos de GitHub."
Ejercicio 3 — Decide si vale la pena crear el repositorio real, para tu propio caso. Sin una respuesta única correcta: ¿en qué escenario crees que tendría sentido, para ti, seguir el pointer opcional de esta lección ahora mismo, y en qué escenario tendría más sentido esperar a completar cloud-security-and-guardrails-guide primero?
Ver solución
Un criterio razonable: si tu objetivo es ver el comentario de PR, la pausa de aprobación, y el rechazo de branch protection con tus propios ojos —sin conectar nada a una cuenta AWS real, dejando apply.yml sin correr o apuntado a un ambiente que nunca aplica nada—, tiene sentido hacerlo ahora, es gratis y de bajo riesgo. Si tu objetivo incluye ver un apply real completarse contra infraestructura real, la recomendación honesta de esta lección es esperar a cloud-security-and-guardrails-guide: conectar credenciales reales de AWS a un repositorio antes de entender OIDC de punta a punta es exactamente el tipo de decisión apurada que produce el antipatrón que el Módulo 4 entero existe para prevenir.
Resumen y siguiente paso
En esta lección consolidaste las cuatro piezas de esta guía que dependen de infraestructura exclusiva de github.com real —comentarios de PR, aprobación de Environments, branch protection, y OIDC federado—, cada una con su causa técnica raíz citada desde el módulo donde apareció por primera vez. Confirmaste que la distinción no es "esta guía está incompleta" sino "pipeline funciona de verdad, plataforma requiere github.com real", y viste el camino opcional —nunca obligatorio— para experimentar las tres primeras piezas con un repositorio público gratuito, con la advertencia explícita de no conectar credenciales reales de AWS sin haber completado la guía de seguridad primero.
Antes de avanzar deberías poder: recitar las cuatro piezas y su causa raíz sin mirar la tabla; explicar la distinción entre "pipeline" y "plataforma" con tus propias palabras; y decidir, para tu propio caso, si seguir el pointer opcional de esta lección tiene sentido ahora o más adelante.
La lección 6 traza una frontera distinta y más amplia: no lo que esta guía no pudo ejecutar por una limitación técnica de act, sino lo que esta guía, por diseño, nunca se propuso construir — la seguridad completa de un pipeline de producción real.
Recursos
- nektos/act discussion #2029 — la fuente de la cita sobre por qué
actno puede emitir tokens OIDC, ya citada completa en el Módulo 4. - nektos/act issue #1714 — la fuente de la cita sobre por qué
actignoraenvironment:, ya citada completa en el Módulo 4. - GitHub Docs — About protected branches — documentación oficial de branch protection, ya citada en el Módulo 6.
- GitHub Docs — Actions billing and usage — confirma que los repositorios públicos no consumen minutos pagos de GitHub Actions, la base del pointer opcional de esta lección.