Fa cinc mòduls que fas servir GitHub Actions: has escrit ci.yml, cd.yml, rollback.yml i infra.yml, has extret la composite action preparar-node i el flux de treball reutilitzable reusable-build-publicar.yml, has federat credencials amb OIDC i has posat concurrency i matrius amb sharding. El que no has fet és mirar l'eina com a eina: què passa exactament entre que algú empeny un commit i arrenca un executor, quins contextos existeixen i quins estan disponibles en quin moment, quins disparadors hi ha més enllà de push i pull_request, com s'escriu una action pròpia quan les existents no hi arriben, quins són els límits reals del servei i què fer quan els toques. Aquesta lliçó tanca aquests buits. No torna a explicar què és una memòria cau ni què és un artefacte immutable —això és a la 04-02 i la 02-06—: explica com els materialitza GitHub Actions, on es trenquen les intuïcions, i quines contrapartides té l'eina que el curs ha fet servir per defecte. Perquè el mòdul va prometre que no hi hauria fanatisme, i això també s'aplica a l'eina de casa.

1. El cicle complet d'un esdeveniment i on viu l'estat
2. Contextos i expressions a fons
3. Tots els disparadors que falten
4. pull_request davant de pull_request_target
5. GITHUB_TOKEN, permissions i OIDC
6. Els tres tipus d'action, amb una JavaScript action completa
7. Matrius avançades i matrius dinàmiques
8. Control de flux: outputs, continue-on-error, timeout-minutes, concurrency
9. Memòria cau i artefactes: claus, límits i desallotjament
10. Executors autoallotjats i autoescalat amb ARC
11. Resums, anotacions i ordres de flux de treball
12. Entorns, regles i desplegaments
13. Límits reals del servei i estratègies
14. Depurar i provar fluxos de treball
15. Errors Comuns i Consells
16. Exercicis
17. Conclusió

Cinc detalls que expliquen comportaments que a molta gent li semblen màgics o trencats:

De quina branca es llegeix el flux de treball. Per a push i pull_request, del commit que dispara. Però per a schedule, workflow_dispatch i workflow_run es llegeix de la branca per defecte, sempre. Per això un schedule nou no s'executa fins que el canvi arriba a main, i per això un workflow_dispatch que arregles en una branca continua comportant-se malament quan el llances.

La definició es congela en arrencar. Si empenys un canvi al flux de treball mentre hi ha una execució en curs, aquella execució continua amb la versió antiga. Serveix per raonar sobre execucions en vol.

Cada job és una màquina nova. No persisteix res entre jobs llevat del que passis explícitament: outputs, artefactes o memòria cau. El que sí que persisteix entre steps del mateix job és el sistema de fitxers, i el procés de shell no (cada run és un shell nou: un export en un step no arriba al següent; per a això hi ha $GITHUB_ENV).

L'executor arriba buit. No hi ha checkout automàtic —a diferència de Travis o GitLab—; per això actions/checkout és sempre el primer pas, i per això oblidar-lo produeix l'error "no such file or directory" més repetit de l'eina.

El resultat es publica com a checks sobre el commit, i són aquests checks els que la protecció de branca de la 02-07 exigeix. Un job que no s'executa per un if fals queda com a skipped, i skipped compta com a aprovat per a la protecció de branca: aquesta asimetria és la causa del "verd fals" més subtil d'Actions, i hi tornarem.

Els contextos són objectes disponibles dins de ${{ }}. Saber quins hi ha i quan estan disponibles evita la meitat dels errors.

1. $GITHUB_OUTPUT és el mecanisme actual (l'antic ::set-output està retirat per motius de seguretat). Per a valors multilínia cal fer servir un delimitador:

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

2. $GITHUB_ENV defineix variables per als steps següents del mateix job; un export normal no surt del step perquè cada run és un shell diferent.

Funcions disponibles, amb els seus usos típics:

I els detalls que mosseguen:

Tots els valors de matrix i dels inputs de workflow_dispatch arriben com a cadena. if: inputs.forcar == true és fals sempre si forcar ve d'un workflow_dispatch; cal comparar amb 'true' o fer servir fromJSON(inputs.forcar).

L'if a nivell de job no porta ${{ }} (encara que funciona amb elles); dins d'una expressió, sí.

if: always() davant de if: ${{ !cancelled() }}: always() executa el step fins i tot si el flux de treball s'ha cancel·lat, cosa que pot deixar recursos a mitges o endarrerir la cancel·lació. Per a "executar encara que falli, però no si cancel·len" —el cas habitual de publicar informes de test— el correcte és if: ${{ !cancelled() }}.

Els secrets no estan disponibles a l'if de nivell de workflow, i tampoc no els pots fer servir per decidir si un flux de treball s'executa. El patró per a "només si hi ha credencials" és un job previ que els comprova i exposa un output booleà.

Més enllà de push i pull_request:

Dos patrons concrets que apareixen molt:

La comprovació d'author_association és imprescindible: sense ella, qualsevol persona d'internet pot disparar un desplegament escrivint un comentari. I el cos del comentari no s'interpola mai dins de run:, perquè és una injecció d'script directa (04-03): si necessites llegir-lo, passa'l per env: i tracta'l com a dada.

La diferència de seguretat més important de tota l'eina. La 04-03 la va enunciar; aquí el mecanisme complet.

Un npm ci executa els scripts postinstall del package.json del PR. Un atacant obre un PR amb un postinstall que envia process.env al seu servidor, i s'emporta tots els secrets. No és teòric: és la manera més comuna de comprometre repositoris públics.

Les regles, sense matisos:

1. Fes servir pull_request per defecte. Cobreix el 95 % dels casos.
2. Fes servir pull_request_target només quan necessitis secrets o escriptura des de forks —etiquetar, comentar, donar format— i sense fer checkout del codi del PR.
3. Si necessites totes dues coses (construir codi d'un fork i comentar el resultat), parteix-ho: un flux de treball pull_request construeix sense secrets i puja un artefacte; un segon flux de treball amb workflow_run el descarrega i comenta. El segon té secrets però mai no executa codi del fork.
4. GITHUB_TOKEN amb permissions mínims sempre, i sobretot aquí.

Aplicat a un repositori privat com el de Reservalia, el risc és menor —només l'equip obre PR— però no nul: un compte compromès n'hi ha prou. I si algun repositori es fa públic algun dia, els fluxos de treball viatgen amb ell.

Cada job rep un GITHUB_TOKEN efímer que mor amb ell. El seu abast depèn de la configuració de l'organització —el valor per defecte pot ser permissiu en repositoris antics— i del que declaris:

Punts que importen:

• Declarar permissions al flux de treball ho posa tot al que has declarat, no només el que has llistat: si poses contents: read, la resta queda en none. És el que vols.
• Els permisos de job substitueixen, no acumulen. Un job amb permissions: { pull-requests: write } perd contents: read i el checkout falla.
• GITHUB_TOKEN no dispara altres fluxos de treball. Un push fet amb ell no llança l'on: push, per disseny, per evitar bucles infinits. Si necessites encadenar, fes servir una GitHub App o un PAT —amb la precaució que llavors sí que pots crear un bucle—.
• OIDC (id-token: write) és el que la 03-02 va establir: l'executor demana un token signat amb reclamacions sobre repositori, branca, entorn i flux, i AWS el canvia per credencials temporals. La condició de confiança a IAM ha de lligar sub amb precisió:

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

  Escriure repo:reservalia/* o deixar el sub amb comodins amplis anul·la la major part de la protecció: qualsevol branca de qualsevol repositori de l'organització podria assumir el rol. És un error de configuració freqüent i greu.

La composite ja la vas escriure a la 04-05. Aquí, una JavaScript action completa: comprova el pressupost de mida del bundle i publica el resultat, un cas real de Reservalia (05-01).

1. getBooleanInput parseja 'true'/'false' correctament. getInput('fallar') === true seria sempre fals: tots els inputs arriben com a cadena, que és el mateix parany de l'apartat 2.
2. core.setOutput publica outputs consumibles amb steps.<id>.outputs.<nom>.
3. core.summary escriu a $GITHUB_STEP_SUMMARY: markdown que apareix a la pàgina del job (apartat 11).
4. core.setFailed marca el pas com a fallit amb missatge; core.warning i core.notice creen anotacions sense fer fallar. Amb file, startLine i endLine l'anotació s'ancora a una línia concreta del codi, que és el que fa útils els linters a la vista de diff.
5. Captura global: sense ella, una excepció produeix una fallada amb traça crua i difícil d'interpretar.

Una funció més que cal conèixer: core.setSecret(valor) registra un valor perquè s'emmascari als logs a partir d'aquell moment. És imprescindible quan la teva action calcula o rep un secret que no venia de secrets —un token obtingut d'una API, per exemple—. I amb la mateixa advertència de la 06-01 i la 06-04: l'emmascarament cobreix la coincidència literal, no les transformacions.

Detall operatiu que sorprèn: una JavaScript action necessita les seves dependències comeses al repositori, perquè l'executor no executa npm install. S'empaqueta amb @vercel/ncc (ncc build src/index.js -o dist) i es comprova al CI que dist/ està sincronitzat amb src/, o publicaràs una action que no conté els teus canvis.

Com triar: composite si són ordres; JavaScript si hi ha lògica, API o outputs calculats; Docker només si necessites dependències del sistema difícils —assumint que només funciona en executors Linux i que arrenca a poc a poc—.

1. fail-fast: true (per defecte) cancel·la tota la matriu a la primera fallada. Estalvia minuts i amaga informació: si volies saber si falla a Node 20 i a Node 22, posa-ho a false. Regla pràctica: false en matrius de compatibilitat, true en shards de la mateixa suite.
2. max-parallel limita la concurrència: útil quan la matriu colpeja un recurs compartit (una base de dades de proves, un límit d'API).
3. include té dos comportaments i aquí hi ha la confusió: si les seves claus coincideixen amb una combinació existent, afegeix propietats a aquella combinació; si no coincideix, crea una combinació nova.
4. exclude s'aplica després d'expandir-ho tot, inclosos els include.

Matriu dinàmica, que és el patró que resol el monorepo de la 04-04:

1. Una matriu buida fa fallar el job, no l'omet. D'aquí l'output hi-ha-canvis i l'if.
2. fromJSON converteix la cadena en un array real per a la matriu.
3. El job porta és la peça clau i la que gairebé ningú no posa. Com que els jobs de matriu tenen noms dinàmics, no es poden exigir pel nom a la protecció de branca; i com que un job skipped compta com a aprovat, sense aquesta porta un PR on els tests s'ometin per un error de detecció passaria la protecció amb tot en verd. És el "verd fals" de la 04-04 en la seva forma més traïdora: no hi ha res vermell per mirar. porta sí que té nom fix, s'executa sempre (if: always()) i comprova needs.test.result explícitament.

1. timeout-minutes a cada job, sense excepció. El valor per defecte són 6 hores: un job penjat consumeix minuts facturables durant tot aquest temps i bloqueja un forat de concurrència. És una línia que estalvia diners reals.
2. continue-on-error: true deixa que el step falli sense trencar el job. També existeix a nivell de job.
3. outcome davant de conclusion: outcome és el resultat abans d'aplicar continue-on-error; conclusion és el resultat final. Amb continue-on-error, conclusion és success encara que outcome sigui failure. Per detectar que alguna cosa ha fallat però no ha bloquejat, es mira outcome.
4. Dos usos diferents de concurrency, i convé no barrejar-los. Per a CI: group: ci-${{ github.ref }} amb cancel-in-progress: true, per cancel·lar execucions obsoletes i estalviar (04-04). Per a desplegaments: cancel-in-progress: false i un grup global, per serialitzar i evitar dos desplegaments simultanis al mateix entorn. Cancel·lar un desplegament a mitges és molt pitjor que esperar.

Un detall que confon: amb concurrency, només es conserva l'execució més recent en espera; les intermèdies es cancel·len. En un desplegament serialitzat, si s'acumulen tres commits, es desplega el primer i l'últim, i el del mig mai. Sol ser el que es vol, però cal saber-ho.

1. La clau ha de contenir tot el que la invalida: sistema operatiu, arquitectura si varia, i el hash dels lockfiles. hashFiles accepta patrons múltiples.
2. restore-keys són prefixos de reserva: sense ells, qualsevol canvi del lockfile obliga a descarregar-ho tot.
3. cache-hit és 'true' només amb coincidència exacta; una restauració parcial per restore-keys deixa cache-hit en false encara que hagi restaurat fitxers. Condicionar npm ci a cache-hit és un error clàssic.

Regles de comportament de la memòria cau que no són òbvies i expliquen moltes raresses:

• L'àmbit de la memòria cau és la branca. Una branca pot llegir les seves pròpies memòries cau i les de la seva branca base; no les de branques germanes. Per això la primera execució d'un PR sol ser més lenta i per això convé que main pobli la memòria cau.
• Les memòries cau són immutables: escrita una clau, no se sobreescriu. Per invalidar, canvia la clau (un prefix versionat hi ajuda).
• Hi ha un límit de mida total per repositori i s'aplica desallotjament per menys usada recentment; a més, les memòries cau no usades durant un temps s'eliminen. Conseqüència pràctica: emmagatzemar diversos gigabytes per branca fa que s'expulsin les unes a les altres i la taxa d'encert es desploma. Menys i millor triat rendeix més.
• La memòria cau no és un canal segur entre branques. Un PR pot escriure en una memòria cau que després restaura una altra execució. No hi guardis binaris construïts que després s'executin amb privilegis (04-03).

Artefactes:

1. A la v4 els noms d'artefacte han de ser únics dins de l'execució: pujar el mateix nom des de diversos jobs de matriu falla. És un canvi respecte de la v3 que trenca molts fluxos de treball heretats.
2. retention-days estalvia emmagatzematge facturable; la política de la 02-06 en una línia.
3. pattern amb merge-multiple recompon els informes de tots els shards en un job d'agregació.

I una diferència amb la memòria cau que convé tenir present: els artefactes es pugen i es descarreguen per xarxa des del servei, no des de l'executor, així que els artefactes grans costen temps als dos extrems. Passar node_modules entre jobs com a artefacte sol ser més lent que reinstal·lar des de memòria cau.

Els executors s'organitzen en grups (per organització) per restringir quins repositoris els poden fer servir —imprescindible si un executor té accés a una xarxa sensible—.

El risc greu, i cal dir-ho clar: no facis servir mai executors autoallotjats en repositoris públics. Qualsevol pot obrir un PR el flux de treball del qual executa codi arbitrari a la teva màquina, dins de la teva xarxa. I si l'executor és persistent, aquell codi pot deixar coses per al job següent —inclòs el d'un altre equip—. GitHub ho adverteix explícitament i l'advertència s'ignora amb massa freqüència.

ARC (Actions Runner Controller) resol el problema de l'executor persistent executant un Pod efímer per job a Kubernetes, que és exactament el model de la 06-05:

1. minRunners: 1 manté un executor calent: sense ell, el primer job del matí paga l'arrencada completa del Pod. És el compromís entre cost i temps de cua que la 04-04 demanava mesurar per separat.
2. containerMode: kubernetes evita Docker-in-Docker privilegiat i fa servir Pods per als contenidors de servei, amb les implicacions de seguretat de la 06-05.

Contrapartides honestes d'ARC: és un component més per operar i actualitzar; l'arrencada del Pod afegeix temps de cua; i la memòria cau no persisteix entre Pods, així que depens de memòria cau remota. A canvi: entorn net per job, autoescalat, i cost proporcional a l'ús a la teva pròpia infraestructura.

Un pipeline el resultat del qual s'ha de buscar en 4.000 línies de log és un pipeline que ningú no mira (03-06). Tres mecanismes ho arreglen:

El resum de job és la millor inversió de llegibilitat que es pot fer en un pipeline amb poc esforç: un enllaç a la previsualització, el digest publicat, el resultat del pressupost de bundle i els tests fallits en una taula estalvien a la Nuria obrir logs cada vegada. I ::add-mask:: és l'equivalent de core.setSecret per a scripts de shell: si el teu script deriva un token, emmascara'l abans que pugui aparèixer en qualsevol sortida.

1. La URL apareix a la interfície de desplegaments i al PR.

El que aporta un Environment, que és més del que sembla:

• Revisors obligatoris: el job espera aprovació humana. És la porta de la 03-01, i el job en espera no consumeix executor —diferència notable davant de l'input de Jenkins (06-01)—.
• Temporitzador d'espera: minuts obligatoris abans de desplegar, per donar marge a cancel·lar.
• Branques i etiquetes permeses: només main pot desplegar a produccio, encara que algú modifiqui el flux de treball en una altra branca.
• Secrets i variables per entorn: secrets.DATABASE_URL val una cosa a staging i una altra a producció, sense condicionals al YAML.
• Historial de desplegaments per entorn amb el seu commit.
• I la peça que més importa combinada amb OIDC: la reclamació sub del token inclou l'entorn, així que el rol d'IAM de producció només es pot assumir des d'un job amb environment: produccio, que al seu torn només es pot executar des de main i després d'aprovació. Tres controls encadenats en comptes d'un.

Sense fanatisme, també amb l'eina de casa. Els valors concrets canvien amb el pla i amb el temps —consulta'ls abans de dissenyar—, però els tipus de límit i les seves estratègies són estables:

Dos límits conceptuals, més importants que els numèrics:

• El pla de control és de GitHub. Si el servei té un incident, no desplegues —ni amb executors propis—. Convé tenir un camí d'emergència documentat: un script que desplegui des d'una màquina amb credencials temporals, assajat. És el mateix raonament de la 03-05 aplicat a l'eina.
• La dependència de l'ecosistema d'actions de tercers és una superfície de subministrament. És la seva fortalesa més gran i un risc real: fixar per SHA (04-03), revisar el que s'afegeix, i preferir ordres de CLI quan l'action només n'embolcalla una.

Notes d'ús real: ACTIONS_STEP_DEBUG mostra quins inputs rep cada action i quines expressions s'avaluen a què, i resol la majoria dels "per què aquest if no es compleix?". toJSON(github.event) és la manera més ràpida de descobrir el nom exacte d'un camp del payload. tmate obre una sessió interactiva en un executor amb els secrets del job: fes-lo servir només en repositoris privats, amb timeout-minutes i preferiblement en un job sense credencials de producció; és el mateix raonament de l'SSH into build de la 06-03.

I act: útil per iterar sobre la lògica d'un job, però no reprodueix l'entorn. No implementa igual les memòries cau, els serveis, els permisos del token, OIDC ni els entorns, i les seves imatges no són les de GitHub. Serveix per a "el meu script funciona?", no per a "el meu flux de treball és correcte?".

Per al segon, l'estratègia de la 04-05 continua sent la bona: actionlint al mateix CI per detectar errors de sintaxi i d'expressions abans de fusionar, una branca de proves on exercitar el flux de treball complet, i canvis progressius amb el pipeline nou en paral·lel al vell.

Oblidar actions/checkout. L'executor arriba buit. És el primer error de tothom.

Esperar que export viatgi entre steps. Cada run és un shell nou: fes servir $GITHUB_ENV.

Comparar inputs booleans amb true. Arriben com a cadena. == 'true' o fromJSON(...).

permissions a nivell de job creient que suma. Substitueix: si poses pull-requests: write sense contents: read, el checkout falla.

pull_request_target amb checkout del codi del PR. És la manera més directa de filtrar tots els teus secrets.

sub d'OIDC amb comodins amplis. repo:org/* permet que qualsevol repositori de l'organització assumeixi el teu rol de producció. Lliga repositori, branca o entorn.

Sense timeout-minutes. El valor per defecte són 6 hores de minuts facturables per un job penjat.

fail-fast: true en matrius de compatibilitat. Cancel·la i amaga la informació que buscaves.

Matriu dinàmica sense job de porta. Els jobs skipped compten com a aprovats a la protecció de branca: verd fals sense res vermell per mirar.

Condicionar la instal·lació a cache-hit. Una restauració parcial deixa cache-hit en false; i encara que encertés, npm ci continua sent necessari.

Guardar node_modules a la memòria cau. Binaris lligats a versió i arquitectura, i ocupa el pressupost de memòria cau del repositori expulsant memòries cau útils.

Executors autoallotjats en repositoris públics. Execució de codi arbitrari dins de la teva xarxa.

Actions de tercers sense fixar per SHA. Una etiqueta és mutable: qui controla el repositori de l'action controla el teu pipeline (04-03).

Noms d'artefacte repetits en matriu amb la v4. Falla la pujada; fes servir un sufix amb l'índex.

if: always() per publicar informes. S'executa també en cancel·lar. Fes servir if: ${{ !cancelled() }}.

Exercici 1. Escriu una JavaScript action verificar-migracions que, donat un directori de migracions, comprovi tres coses: que no hi ha dos fitxers amb el mateix número de versió, que cap migració nova del PR no conté DROP COLUMN o DROP TABLE (la regla d'expand and contract de la 04-06), i que cada migració té el seu fitxer de reversió. Ha d'exposar outputs, escriure un resum de job, generar anotacions ancorades al fitxer i poder configurar-se com a bloquejant o informativa.

Exercici 2. Un repositori públic de Reservalia té aquest flux de treball. Troba tots els problemes de seguretat, explica l'impacte de cadascun i reescriu-lo:

Exercici 3. El ci.yml de Reservalia triga 11 minuts i l'equip es queixa que "GitHub Actions va lent". Les dades: el temps mitjà en cua és de 4 minuts entre les 10:00 i les 12:00; els sis jobs restauren memòria cau però la taxa d'encert és del 40 %; la matriu de tests té fail-fast: true i sovint es cancel·la per una prova inestable; hi ha tres jobs sense timeout-minutes i un es queda penjat un parell de vegades per setmana; i la memòria cau total del repositori està al límit amb 9 GB, la majoria en node_modules de branques velles. Diagnostica cada punt i dona un pla ordenat.

Solució 1.

Decisions de disseny que convé justificar. La numeració duplicada es comprova sobre tot el directori, perquè la col·lisió pot venir de dos PR oberts en paral·lel que individualment són correctes —és un problema d'integració, no de fitxer—. Les operacions destructives i la reversió es comproven només sobre les migracions noves, perquè les històriques ja es van aplicar i marcar-les seria soroll que faria ignorar l'eina. L'input fallar permet el desplegament progressiu de la 04-05: primer informativa durant dues setmanes per mesurar quant soroll genera, després bloquejant. I les anotacions ancorades a fitxer i línia apareixen a la vista de diff, on el revisor les veu sense obrir logs. L'ús requereix fetch-depth: 0 i passar base: ${{ github.event.pull_request.base.sha }}.

Solució 2. Sis problemes, tres dels quals greus:

Reescriptura en dos fluxos de treball, que és el patró correcte:

La idea central: separar el privilegi de l'execució de codi no confiable. El primer flux de treball executa codi del PR sense cap secret i amb permisos de només lectura; el segon té permís d'escriptura però només processa dades ja generades i mai no executa codi del fork. Fixa't a més que el títol del PR desapareix del comentari: no aportava res i era el vector d'injecció. I que les dades es passen per env, no interpolades al cos de l'script, que és la regla general per a qualsevol dada d'origen extern.

Solució 3. El diagnòstic separa dues coses que l'equip està barrejant: 11 minuts d'execució i 4 de cua són problemes diferents amb causes diferents, i dir-ho tot "GitHub Actions va lent" impedeix arreglar-ne cap.

Ordre i raons. Primer el punt 1, perquè costa cinc minuts de feina i és causa parcial del punt 3: jobs penjats ocupant forats de concurrència són part de la cua. Després el 2, que és l'estalvi de temps més gran per esforç i a més allibera pressupost de memòria cau. Després el 4, amb el matís important: fail-fast: false redueix el símptoma però el problema real és la prova inestable, i deixar-la sense quarantena mentre s'amaga el símptoma és exactament el que la 02-04 advertia. I només llavors el 3 i el 5, quan es pugui mesurar quant queda de cada cosa.

El que cal endur-se: dels cinc punts, tres no són de l'eina —una prova inestable sense quarantena, jobs sense timeout, memòria cau mal triada— sinó de com s'està fent servir. La conclusió que cal portar a l'equip és que abans de canviar d'eina o de pagar més concurrència, cal separar cua d'execució i arreglar el que és propi, que és literalment la primera regla de la 04-04. Si després d'això la cua continua sent el coll d'ampolla, llavors sí que hi ha una conversa legítima sobre pla o executors propis, i aquesta conversa es té amb dades.

GitHub Actions ha estat l'eina del curs des del mòdul 2, i aquesta lliçó l'ha mirat per fi com a objecte d'estudi. El que tanca els buits que quedaven: el cicle d'un esdeveniment i de quina branca es llegeix el flux de treball —que explica per què schedule i workflow_run es comporten com es comporten—; els contextos, amb el parany que tots els inputs són cadenes; els disparadors que faltaven i la regla d'or de pull_request davant de pull_request_target; els permisos que substitueixen en comptes de sumar i el sub d'OIDC que cal lligar amb precisió; els tres tipus d'action i quan baixar a JavaScript; les matrius dinàmiques amb el seu job de porta obligatori; el comportament real de la memòria cau amb el seu àmbit per branca i el seu desallotjament; ARC per a executors efímers; i els límits del servei amb les seves estratègies.

Les contrapartides, dites sense adorns, perquè el mòdul va prometre no fer màrqueting amb cap eina: el pla de control no és teu i un incident del servei et deixa sense desplegar; l'ecosistema d'actions de tercers és la seva fortalesa més gran i una superfície de subministrament real; la memòria cau té un pressupost per repositori que castiga l'excés; schedule no és puntual i s'apaga sol; hi ha asimetries perilloses com que un job skipped compti com a aprovat; i pull_request_target és un peu de guerra permanent en repositoris públics. Cap d'aquestes coses no la fa mala elecció —per a un equip el codi del qual ja és a GitHub continua sent l'opció per defecte més raonable—, però conèixer-les és la diferència entre fer-la servir i patir-la.

Amb això queden les sis eines recorregudes i el mateix pipeline de Reservalia traduït sis vegades. La lliçó que tanca el mòdul, Comparativa i Criteris per Triar Eina, ho posa tot a la mateixa taula: la taula d'equivalències de vocabulari, la comparació per dimensions —model d'execució, allotjament, reutilització, identitat, cost—, els criteris de decisió ordenats pel seu pes real (amb un factor que decideix el 80 % dels casos), un arbre de decisió, un exercici de cost total de propietat, el cost de canviar d'eina i com reduir-lo, i una guia de migració per fases. I després, el mòdul 7: construir el teu propi pipeline d'extrem a extrem.