Llevas cinco módulos usando GitHub Actions: has escrito ci.yml, cd.yml, rollback.yml e infra.yml, has extraído la composite action preparar-node y el workflow reutilizable reusable-build-publicar.yml, has federado credenciales con OIDC y has puesto concurrency y matrices con sharding. Lo que no has hecho es mirar la herramienta como herramienta: qué ocurre exactamente entre que alguien empuja un commit y arranca un runner, qué contextos existen y cuáles están disponibles en qué momento, qué disparadores hay más allá de push y pull_request, cómo se escribe una action propia cuando las existentes no llegan, cuáles son los límites reales del servicio y qué hacer cuando los tocas. Esta lección cierra esos huecos. No re-explica qué es una caché ni qué es un artefacto inmutable —eso está en la 04-02 y la 02-06—: explica cómo los materializa GitHub Actions, dónde se rompen las intuiciones, y qué contrapartidas tiene la herramienta que el curso ha usado por defecto. Porque el módulo prometió que no habría fanatismo, y esto también aplica a la herramienta de casa.

1. El ciclo completo de un evento y dónde vive el estado
2. Contextos y expresiones a fondo
3. Todos los disparadores que faltan
4. pull_request frente a pull_request_target
5. GITHUB_TOKEN, permissions y OIDC
6. Los tres tipos de action, con una JavaScript action completa
7. Matrices avanzadas y matrices dinámicas
8. Control de flujo: outputs, continue-on-error, timeout-minutes, concurrency
9. Caché y artefactos: claves, límites y desalojo
10. Runners autoalojados y autoescalado con ARC
11. Resúmenes, anotaciones y comandos de workflow
12. Entornos, reglas y despliegues
13. Límites reales del servicio y estrategias
14. Depurar y probar workflows
15. Errores Comunes y Consejos
16. Ejercicios
17. Conclusión

Cinco detalles que explican comportamientos que a mucha gente le parecen mágicos o rotos:

De qué rama se lee el workflow. Para push y pull_request, del commit que dispara. Pero para schedule, workflow_dispatch y workflow_run se lee de la rama por defecto, siempre. Por eso un schedule nuevo no se ejecuta hasta que el cambio llega a main, y por eso un workflow_dispatch que arreglas en una rama sigue comportándose mal al lanzarlo.

La definición se congela al arrancar. Si empujas un cambio al workflow mientras hay una ejecución en curso, esa ejecución sigue con la versión antigua. Sirve para razonar sobre ejecuciones en vuelo.

Cada job es una máquina nueva. Nada persiste entre jobs salvo lo que pases explícitamente: outputs, artefactos o caché. Lo que sí persiste entre steps del mismo job es el sistema de ficheros y el proceso de shell no (cada run es un shell nuevo: un export en un step no llega al siguiente; para eso está $GITHUB_ENV).

El runner llega vacío. No hay checkout automático —a diferencia de Travis o GitLab—; por eso actions/checkout es siempre el primer paso, y por eso olvidarlo produce el error "no such file or directory" más repetido de la herramienta.

El resultado se publica como checks sobre el commit, y son esos checks los que la protección de rama de la 02-07 exige. Un job que no se ejecuta por un if falso queda como skipped, y skipped cuenta como aprobado para la protección de rama: esa asimetría es la causa del "verde falso" más sutil de Actions, y volveremos a ella.

Los contextos son objetos disponibles dentro de ${{ }}. Saber cuáles hay y cuándo están disponibles evita la mitad de los errores.

1. $GITHUB_OUTPUT es el mecanismo actual (el antiguo ::set-output está retirado por motivos de seguridad). Para valores multilínea hay que usar un delimitador:

   {
     echo "notas<<EOF"
     cat CHANGELOG.md
     echo "EOF"
   } >> "$GITHUB_OUTPUT"
   

2. $GITHUB_ENV define variables para los steps siguientes del mismo job; un export normal no sale del step porque cada run es un shell distinto.

Funciones disponibles, con sus usos típicos:

Y los detalles que muerden:

Todos los valores de matrix y de inputs de workflow_dispatch llegan como cadena. if: inputs.forzar == true es falso siempre si forzar viene de un workflow_dispatch; hay que comparar con 'true' o usar fromJSON(inputs.forzar).

if a nivel de job no lleva ${{ }} (aunque funciona con ellas); dentro de una expresión, sí.

if: always() frente a if: ${{ !cancelled() }}: always() ejecuta el step incluso si el workflow fue cancelado, lo que puede dejar recursos a medias o retrasar la cancelación. Para "ejecutar aunque falle, pero no si cancelan" —el caso habitual de publicar informes de test— lo correcto es if: ${{ !cancelled() }}.

Los secretos no están disponibles en if de nivel de workflow, y tampoco puedes usarlos para decidir si un workflow se ejecuta. El patrón para "solo si hay credenciales" es un job previo que los comprueba y expone un output booleano.

Más allá de push y pull_request:

Dos patrones concretos que aparecen mucho:

La comprobación de author_association es imprescindible: sin ella, cualquier persona de internet puede disparar un despliegue escribiendo un comentario. Y el cuerpo del comentario no se interpola nunca dentro de run:, porque es una inyección de script directa (04-03): si necesitas leerlo, pásalo por env: y trátalo como dato.

La diferencia más importante de seguridad de toda la herramienta. La 04-03 la enunció; aquí el mecanismo completo.

Un npm ci ejecuta los scripts postinstall del package.json del PR. Un atacante abre un PR con un postinstall que envía process.env a su servidor, y se lleva todos los secretos. No es teórico: es la forma más común de comprometer repositorios públicos.

Las reglas, sin matices:

1. Usa pull_request por defecto. Cubre el 95 % de los casos.
2. Usa pull_request_target solo cuando necesites secretos o escritura desde forks —etiquetar, comentar, dar formato— y sin hacer checkout del código del PR.
3. Si necesitas ambas cosas (construir código de un fork y comentar el resultado), pártelo: un workflow pull_request construye sin secretos y sube un artefacto; un segundo workflow con workflow_run lo descarga y comenta. El segundo tiene secretos pero nunca ejecuta código del fork.
4. GITHUB_TOKEN con permissions mínimos siempre, y sobre todo aquí.

Aplicado a un repositorio privado como el de Reservalia, el riesgo es menor —solo el equipo abre PR— pero no nulo: una cuenta comprometida basta. Y si algún repositorio se hace público algún día, los workflows viajan con él.

Cada job recibe un GITHUB_TOKEN efímero que muere con él. Su alcance depende de la configuración de la organización —el valor por defecto puede ser permisivo en repositorios antiguos— y de lo que declares:

Puntos que importan:

• Declarar permissions en el workflow lo pone todo a lo declarado, no solo lo listado: si pones contents: read, el resto queda en none. Es lo que quieres.
• Los permisos de job sustituyen, no acumulan. Un job con permissions: { pull-requests: write } pierde contents: read y el checkout falla.
• GITHUB_TOKEN no dispara otros workflows. Un push hecho con él no lanza el on: push, por diseño, para evitar bucles infinitos. Si necesitas encadenar, usa una GitHub App o un PAT —con la precaución de que entonces sí puedes crear un bucle—.
• OIDC (id-token: write) es lo que la 03-02 estableció: el runner pide un token firmado con reclamaciones sobre repositorio, rama, entorno y flujo, y AWS lo cambia por credenciales temporales. La condición de confianza en IAM debe atar sub con precisión:

  "StringLike": { "token.actions.githubusercontent.com:sub": "repo:reservalia/reservalia:environment:produccion" }
  

  Escribir repo:reservalia/* o dejar el sub con comodines amplios anula la mayor parte de la protección: cualquier rama de cualquier repositorio de la organización podría asumir el rol. Es un error de configuración frecuente y grave.

La composite ya la escribiste en la 04-05. Aquí, una JavaScript action completa: comprueba el presupuesto de tamaño del bundle y publica el resultado, un caso real de Reservalia (05-01).

1. getBooleanInput parsea 'true'/'false' correctamente. getInput('fallar') === true sería siempre falso: todos los inputs llegan como cadena, que es la misma trampa del apartado 2.
2. core.setOutput publica outputs consumibles con steps.<id>.outputs.<nombre>.
3. core.summary escribe en $GITHUB_STEP_SUMMARY: markdown que aparece en la página del job (apartado 11).
4. core.setFailed marca el paso como fallido con mensaje; core.warning y core.notice crean anotaciones sin fallar. Con file, startLine y endLine la anotación se ancla a una línea concreta del código, que es lo que hace útiles a los linters en la vista de diff.
5. Captura global: sin ella, una excepción produce un fallo con traza cruda y difícil de interpretar.

Una función más que hay que conocer: core.setSecret(valor) registra un valor para que se enmascare en los logs a partir de ese momento. Es imprescindible cuando tu action calcula o recibe un secreto que no venía de secrets —un token obtenido de una API, por ejemplo—. Y con la misma advertencia de la 06-01 y la 06-04: el enmascarado cubre la coincidencia literal, no las transformaciones.

Detalle operativo que sorprende: una JavaScript action necesita sus dependencias comprometidas en el repositorio, porque el runner no ejecuta npm install. Se empaqueta con @vercel/ncc (ncc build src/index.js -o dist) y se comprueba en CI que dist/ está sincronizado con src/, o publicarás una action que no contiene tus cambios.

Cómo elegir: composite si son comandos; JavaScript si hay lógica, API o outputs calculados; Docker solo si necesitas dependencias del sistema difíciles —asumiendo que solo funciona en runners Linux y que arranca despacio—.

1. fail-fast: true (por defecto) cancela toda la matriz al primer fallo. Ahorra minutos y oculta información: si querías saber si falla en Node 20 y en Node 22, ponlo en false. Regla práctica: false en matrices de compatibilidad, true en shards de la misma suite.
2. max-parallel limita la concurrencia: útil cuando la matriz golpea un recurso compartido (una base de datos de pruebas, un límite de API).
3. include tiene dos comportamientos y ahí está la confusión: si sus claves coinciden con una combinación existente, añade propiedades a esa combinación; si no coincide, crea una combinación nueva.
4. exclude se aplica después de expandir todo, incluidos los include.

Matriz dinámica, que es el patrón que resuelve el monorepo de la 04-04:

1. Una matriz vacía hace fallar el job, no lo omite. De ahí el output hay-cambios y el if.
2. fromJSON convierte la cadena en un array real para la matriz.
3. El job puerta es la pieza clave y la que casi nadie pone. Como los jobs de matriz tienen nombres dinámicos, no se pueden exigir por nombre en la protección de rama; y como un job skipped cuenta como aprobado, sin esta puerta un PR donde los tests se omiten por un error de detección pasaría la protección con todo en verde. Es el "verde falso" de la 04-04 en su forma más traicionera: no hay nada rojo que mirar. puerta sí tiene nombre fijo, se ejecuta siempre (if: always()) y comprueba needs.test.result explícitamente.

1. timeout-minutes en cada job, sin excepción. El valor por defecto son 6 horas: un job colgado consume minutos facturables durante todo ese tiempo y bloquea un hueco de concurrencia. Es una línea que ahorra dinero real.
2. continue-on-error: true deja que el step falle sin romper el job. También existe a nivel de job.
3. outcome frente a conclusion: outcome es el resultado antes de aplicar continue-on-error; conclusion es el resultado final. Con continue-on-error, conclusion es success aunque outcome sea failure. Para detectar que algo falló pero no bloqueó, se mira outcome.
4. Dos usos distintos de concurrency, y conviene no mezclarlos. Para CI: group: ci-${{ github.ref }} con cancel-in-progress: true, para cancelar ejecuciones obsoletas y ahorrar (04-04). Para despliegues: cancel-in-progress: false y un grupo global, para serializar y evitar dos despliegues simultáneos al mismo entorno. Cancelar un despliegue a medias es mucho peor que esperar.

Un detalle que confunde: con concurrency, solo se conserva la ejecución más reciente en espera; las intermedias se cancelan. En un despliegue serializado, si se acumulan tres commits, se despliega el primero y el último, y el del medio nunca. Suele ser lo deseable, pero hay que saberlo.

1. La clave debe contener todo lo que invalida: sistema operativo, arquitectura si varía, y el hash de los lockfiles. hashFiles acepta patrones múltiples.
2. restore-keys son prefijos de reserva: sin ellos, cualquier cambio del lockfile obliga a descargar todo.
3. cache-hit es 'true' solo con coincidencia exacta; una restauración parcial por restore-keys deja cache-hit en false aunque haya restaurado ficheros. Condicionar npm ci a cache-hit es un error clásico.

Reglas de comportamiento de la caché que no son obvias y explican muchas rarezas:

• El ámbito de la caché es la rama. Una rama puede leer sus propias cachés y las de su rama base; no las de ramas hermanas. Por eso la primera ejecución de un PR suele ser más lenta y por eso conviene que main pueble la caché.
• Las cachés son inmutables: escrita una clave, no se sobrescribe. Para invalidar, cambia la clave (un prefijo versionado ayuda).
• Hay un límite de tamaño total por repositorio y se aplica desalojo por menos usada recientemente; además, las cachés no usadas durante un tiempo se eliminan. Consecuencia práctica: cachear varios gigabytes por rama hace que se expulsen unas a otras y la tasa de acierto se desploma. Menos y mejor elegido rinde más.
• La caché no es un canal seguro entre ramas. Un PR puede escribir en una caché que después restaura otra ejecución. No caches binarios construidos que luego se ejecuten con privilegios (04-03).

Artefactos:

1. En v4 los nombres de artefacto deben ser únicos dentro de la ejecución: subir el mismo nombre desde varios jobs de matriz falla. Es un cambio respecto a v3 que rompe muchos workflows heredados.
2. retention-days ahorra almacenamiento facturable; la política de la 02-06 en una línea.
3. pattern con merge-multiple recompone los informes de todos los shards en un job de agregación.

Y una diferencia con la caché que conviene tener presente: los artefactos se suben y descargan por red desde el servicio, no desde el runner, así que artefactos grandes cuestan tiempo en ambos extremos. Pasar node_modules entre jobs como artefacto suele ser más lento que reinstalar desde caché.

Los runners se organizan en grupos (por organización) para restringir qué repositorios pueden usarlos —imprescindible si un runner tiene acceso a una red sensible—.

El riesgo grave, y hay que decirlo claro: nunca uses runners autoalojados en repositorios públicos. Cualquiera puede abrir un PR cuyo workflow ejecuta código arbitrario en tu máquina, dentro de tu red. Y si el runner es persistente, ese código puede dejar cosas para el siguiente job —incluido el de otro equipo—. GitHub lo advierte explícitamente y la advertencia se ignora con demasiada frecuencia.

ARC (Actions Runner Controller) resuelve el problema del runner persistente ejecutando un Pod efímero por job en Kubernetes, que es exactamente el modelo de la 06-05:

1. minRunners: 1 mantiene un runner caliente: sin él, el primer job de la mañana paga el arranque completo del Pod. Es el compromiso entre coste y tiempo de cola que la 04-04 pedía medir por separado.
2. containerMode: kubernetes evita Docker-in-Docker privilegiado y usa Pods para los contenedores de servicio, con las implicaciones de seguridad de la 06-05.

Contrapartidas honestas de ARC: es un componente más que operar y actualizar; el arranque del Pod añade tiempo de cola; y la caché no persiste entre Pods, así que dependes de caché remota. A cambio: entorno limpio por job, autoescalado, y coste proporcional al uso en tu propia infraestructura.

Un pipeline cuyo resultado hay que buscar en 4.000 líneas de log es un pipeline que nadie mira (03-06). Tres mecanismos lo arreglan:

El resumen de job es la mejor inversión de legibilidad que se puede hacer en un pipeline con poco esfuerzo: un enlace a la previsualización, el digest publicado, el resultado del presupuesto de bundle y los tests fallidos en una tabla ahorran a Nuria abrir logs cada vez. Y ::add-mask:: es el equivalente de core.setSecret para scripts en shell: si tu script deriva un token, enmascáralo antes de que pueda aparecer en cualquier salida.

1. La URL aparece en la interfaz de despliegues y en el PR.

Lo que aporta un Environment, que es más de lo que parece:

• Revisores obligatorios: el job espera aprobación humana. Es la puerta de la 03-01, y el job en espera no consume runner —diferencia notable frente al input de Jenkins (06-01)—.
• Temporizador de espera: minutos obligatorios antes de desplegar, para dar margen a cancelar.
• Ramas y tags permitidos: solo main puede desplegar a produccion, aunque alguien modifique el workflow en otra rama.
• Secretos y variables por entorno: secrets.DATABASE_URL vale una cosa en staging y otra en producción, sin condicionales en el YAML.
• Historial de despliegues por entorno con su commit.
• Y la pieza que más importa combinada con OIDC: la reclamación sub del token incluye el entorno, así que el rol de IAM de producción solo puede asumirse desde un job con environment: produccion, que a su vez solo puede ejecutarse desde main y tras aprobación. Tres controles encadenados en lugar de uno.

Sin fanatismo, también con la herramienta de casa. Los valores concretos cambian con el plan y con el tiempo —consúltalos antes de diseñar—, pero los tipos de límite y sus estrategias son estables:

Dos límites conceptuales, más importantes que los numéricos:

• El plano de control es de GitHub. Si el servicio tiene una incidencia, no despliegas —ni con runners propios—. Conviene tener un camino de emergencia documentado: un script que despliegue desde una máquina con credenciales temporales, ensayado. Es el mismo razonamiento de la 03-05 aplicado a la herramienta.
• La dependencia del ecosistema de acciones de terceros es una superficie de suministro. Es su mayor fortaleza y un riesgo real: fijar por SHA (04-03), revisar lo que se añade, y preferir comandos de CLI cuando la action solo envuelve uno.

Notas de uso real: ACTIONS_STEP_DEBUG muestra qué inputs recibe cada action y qué expresiones se evalúan a qué, y resuelve la mayoría de los "¿por qué este if no se cumple?". toJSON(github.event) es la forma más rápida de descubrir el nombre exacto de un campo del payload. tmate abre una sesión interactiva en un runner con los secretos del job: úsalo solo en repositorios privados, con timeout-minutes y preferiblemente en un job sin credenciales de producción; es el mismo razonamiento del SSH into build de la 06-03.

Y act: útil para iterar sobre la lógica de un job, pero no reproduce el entorno. No implementa igual las cachés, los servicios, los permisos del token, OIDC ni los entornos, y sus imágenes no son las de GitHub. Sirve para "¿mi script funciona?", no para "¿mi workflow es correcto?".

Para lo segundo, la estrategia de la 04-05 sigue siendo la buena: actionlint en el propio CI para detectar errores de sintaxis y expresiones antes de fusionar, una rama de pruebas donde ejercitar el workflow completo, y cambios progresivos con el pipeline nuevo en paralelo al viejo.

Olvidar actions/checkout. El runner llega vacío. Es el primer error de todo el mundo.

Esperar que export viaje entre steps. Cada run es un shell nuevo: usa $GITHUB_ENV.

Comparar inputs booleanos con true. Llegan como cadena. == 'true' o fromJSON(...).

permissions a nivel de job creyendo que suma. Sustituye: si pones pull-requests: write sin contents: read, el checkout falla.

pull_request_target con checkout del código del PR. Es la forma más directa de filtrar todos tus secretos.

sub de OIDC con comodines amplios. repo:org/* permite que cualquier repositorio de la organización asuma tu rol de producción. Ata repositorio, rama o entorno.

Sin timeout-minutes. El valor por defecto son 6 horas de minutos facturables por un job colgado.

fail-fast: true en matrices de compatibilidad. Cancela y oculta la información que buscabas.

Matriz dinámica sin job de puerta. Los jobs skipped cuentan como aprobados en la protección de rama: verde falso sin nada rojo que mirar.

Condicionar la instalación a cache-hit. Una restauración parcial deja cache-hit en false; y aunque acertara, npm ci sigue siendo necesario.

Cachear node_modules. Binarios atados a versión y arquitectura, y ocupa el presupuesto de caché del repositorio expulsando cachés útiles.

Runners autoalojados en repositorios públicos. Ejecución de código arbitrario dentro de tu red.

Acciones de terceros sin fijar por SHA. Un tag es mutable: quien controla el repositorio de la action controla tu pipeline (04-03).

Nombres de artefacto repetidos en matriz con v4. Falla la subida; usa sufijo con el índice.

if: always() para publicar informes. Se ejecuta también al cancelar. Usa if: ${{ !cancelled() }}.

Ejercicio 1. Escribe una JavaScript action verificar-migraciones que, dado un directorio de migraciones, compruebe tres cosas: que no hay dos ficheros con el mismo número de versión, que ninguna migración nueva del PR contiene DROP COLUMN o DROP TABLE (la regla de expand and contract de la 04-06), y que cada migración tiene su fichero de reversión. Debe exponer outputs, escribir un resumen de job, generar anotaciones ancladas al fichero y poder configurarse como bloqueante o informativa.

Ejercicio 2. Un repositorio público de Reservalia tiene este workflow. Encuentra todos los problemas de seguridad, explica el impacto de cada uno y reescríbelo:

Ejercicio 3. El ci.yml de Reservalia tarda 11 minutos y el equipo se queja de que "GitHub Actions va lento". Los datos: el tiempo medio en cola es de 4 minutos entre las 10:00 y las 12:00; los seis jobs restauran caché pero la tasa de acierto es del 40 %; la matriz de tests tiene fail-fast: true y a menudo se cancela por un flaky; hay tres jobs sin timeout-minutes y uno se queda colgado un par de veces por semana; y la caché total del repositorio está al límite con 9 GB, la mayoría en node_modules de ramas viejas. Diagnostica cada punto y da un plan ordenado.

Solución 1.

Decisiones de diseño que conviene justificar. La numeración duplicada se comprueba sobre todo el directorio, porque la colisión puede venir de dos PR abiertos en paralelo que individualmente son correctos —es un problema de integración, no de fichero—. Las operaciones destructivas y la reversión se comprueban solo sobre las migraciones nuevas, porque las históricas ya se aplicaron y marcarlas sería ruido que haría ignorar la herramienta. El input fallar permite el despliegue progresivo de la 04-05: primero informativa durante dos semanas para medir cuánto ruido genera, luego bloqueante. Y las anotaciones ancladas a fichero y línea aparecen en la vista de diff, donde el revisor las ve sin abrir logs. El uso requiere fetch-depth: 0 y pasar base: ${{ github.event.pull_request.base.sha }}.

Solución 2. Seis problemas, tres de ellos graves:

Reescritura en dos workflows, que es el patrón correcto:

La idea central: separar el privilegio de la ejecución de código no confiable. El primer workflow ejecuta código del PR sin ningún secreto y con permisos de solo lectura; el segundo tiene permiso de escritura pero solo procesa datos ya generados y nunca ejecuta código del fork. Nótese además que el título del PR desaparece del comentario: no aportaba nada y era el vector de inyección. Y que los datos se pasan por env, no interpolados en el cuerpo del script, que es la regla general para cualquier dato de origen externo.

Solución 3. El diagnóstico separa dos cosas que el equipo está mezclando: 11 minutos de ejecución y 4 de cola son problemas distintos con causas distintas, y llamarlo todo "GitHub Actions va lento" impide arreglar ninguno.

Orden y razones. Primero el punto 1, porque cuesta cinco minutos de trabajo y es causa parcial del punto 3: jobs colgados ocupando huecos de concurrencia son parte de la cola. Luego el 2, que es el ahorro de tiempo más grande por esfuerzo y además libera presupuesto de caché. Después el 4, con el matiz importante: fail-fast: false reduce el síntoma pero el problema real es el flaky, y dejarlo sin cuarentena mientras se esconde el síntoma es exactamente lo que la 02-04 advertía. Y solo entonces el 3 y el 5, cuando se pueda medir cuánto queda de cada cosa.

Lo que hay que llevarse: de los cinco puntos, tres no son de la herramienta —un flaky sin cuarentena, jobs sin timeout, caché mal elegida— y sí de cómo se está usando. La conclusión que hay que llevar al equipo es que antes de cambiar de herramienta o de pagar más concurrencia, hay que separar cola de ejecución y arreglar lo propio, que es literalmente la primera regla de la 04-04. Si tras esto la cola sigue siendo el cuello de botella, entonces sí hay una conversación legítima sobre plan o runners propios, y esa conversación se tiene con datos.

GitHub Actions ha sido la herramienta del curso desde el módulo 2, y esta lección la ha mirado por fin como objeto de estudio. Lo que cierra los huecos que quedaban: el ciclo de un evento y de qué rama se lee el workflow —que explica por qué schedule y workflow_run se comportan como se comportan—; los contextos, con la trampa de que todos los inputs son cadenas; los disparadores que faltaban y la regla de oro de pull_request frente a pull_request_target; los permisos que sustituyen en vez de sumar y el sub de OIDC que hay que atar con precisión; los tres tipos de action y cuándo bajar a JavaScript; las matrices dinámicas con su job de puerta obligatorio; el comportamiento real de la caché con su ámbito por rama y su desalojo; ARC para runners efímeros; y los límites del servicio con sus estrategias.

Las contrapartidas, dichas sin adornos, porque el módulo prometió no hacer marketing con ninguna herramienta: el plano de control no es tuyo y una incidencia del servicio te deja sin desplegar; el ecosistema de acciones de terceros es su mayor fortaleza y una superficie de suministro real; la caché tiene un presupuesto por repositorio que castiga el exceso; schedule no es puntual y se apaga solo; hay asimetrías peligrosas como que un job skipped cuente como aprobado; y pull_request_target es un pie de guerra permanente en repositorios públicos. Ninguna de esas cosas la hace mala elección —para un equipo cuyo código ya está en GitHub sigue siendo la opción por defecto más razonable—, pero conocerlas es la diferencia entre usarla y sufrirla.

Con esto quedan las seis herramientas recorridas y el mismo pipeline de Reservalia traducido seis veces. La lección que cierra el módulo, Comparativa y Criterios para Elegir Herramienta, pone todo en la misma mesa: la tabla de equivalencias de vocabulario, la comparación por dimensiones —modelo de ejecución, alojamiento, reutilización, identidad, coste—, los criterios de decisión ordenados por su peso real (con un factor que decide el 80 % de los casos), un árbol de decisión, un ejercicio de coste total de propiedad, el coste de cambiar de herramienta y cómo reducirlo, y una guía de migración por fases. Y después, el módulo 7: construir tu propio pipeline de extremo a extremo.