GitHub Actions

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 1 din 14. Majoritatea build-urilor enterprise sunt tratate ca ceva secundar într-un tool complet separat. Faci push la cod, are loc un context switch și speri că un webhook se declanșează corect pe un server remote, undeva în altă parte. Abordarea enterprise pentru GitHub Actions rezolvă această lacună mutând execuția pipeline-ului direct lângă codul sursă. O concepție greșită frecventă este tratarea GitHub Actions strict ca un tool de CI/CD, ca și cum ar fi doar un înlocuitor modern pentru Jenkins. Numește-l așa cum e de fapt. Este un motor de automatizare flexibil, event-driven, profund încorporat în repository-ul tău. Răspunde practic la orice schimbare de stare din cadrul platformei de version control. Uită-te la un setup enterprise standard care folosește tool-uri precum GCP Cloud Build sau Azure DevOps. Codul sursă se află în GitHub, dar execuția are loc în altă parte. Asta necesită gestionarea de service accounts cross-platform, menținerea unor webhook-uri fragile și sincronizarea de access controls între mai mulți vendori. Când un pipeline pică, developerii părăsesc repository-ul, se loghează într-o consolă cloud separată și sapă prin log-uri deconectate de pull request-ul lor. Proximitatea față de cod elimină această fricțiune. Când motorul tău de automatizare este integrat direct în platforma de version control, elimini taxa de integrare. Identitatea utilizatorului, regulile de branch protection și contextul modificării de cod sunt înțelese nativ de instanța de compute care îți rulează pipeline-ul. Ia în considerare un pipeline tradițional într-un cloud build tool separat. De obicei, acesta așteaptă un code commit, face pull la sursă, face build unui artifact și raportează un status simplu de pass sau fail înapoi în repository. Întreaga sa viziune asupra lumii este limitată la compilarea codului și deployment. Un GitHub Action operează la o scară mult mai largă. Pentru că înțelege nativ evenimentele din repository, poți construi un workflow care se declanșează exact în momentul în care se deschide un pull request. Într-un singur run fluid, poate citi event payload-ul, poate asigna senior engineerii potriviți ca reviewers în funcție de fișierele specifice modificate, poate executa un linter și poate posta orice erori de sintaxă direct ca niște comentarii inline pe liniile exacte de cod. Developerul rezolvă problemele fără să părăsească vreodată view-ul de pull request. Automatizezi workflow-ul în sine, nu doar build artifact-ul. Din punct de vedere arhitectural, asta îți transformă repository-ul dintr-un volum de stocare pasiv într-un controller activ. Nu mai automatizezi doar deployment-urile și începi să automatizezi guvernanța operațională. Dacă un issue este marcat cu un label critic, un action poate proviziona automat o bază de date temporară de testare. Dacă o vulnerabilitate de securitate este semnalată de un dependency scan automat, un action poate deschide instantaneu un tracking ticket, poate asigna echipa de securitate și poate da un ping pe sistemul tău de chat intern. Totul utilizează exact aceeași infrastructură de compute subiacentă. Într-o organizație mare, poți defini aceste workflow-uri centralizat și le poți partaja în sute de repository-uri. Dacă echipa ta de securitate actualizează politica necesară de container scanning, ei actualizează un singur action central. Fiecare repository care apelează acel action moștenește imediat noua cerință de securitate, fără ca echipele individuale de produs să își rescrie scripturile de pipeline. Această centralizare oferă un avantaj masiv pentru echipele de platform engineering. Iată perspectiva cheie. Arhitectura enterprise se confruntă constant cu tool sprawl. Fiecare tool nou de pipeline adaugă cognitive load, necesită mentenanță dedicată și creează o altă suprafață pentru politicile de securitate. Prin consolidarea layer-ului de execuție direct în GitHub, standardizezi modul în care se comportă fiecare repository. Exact aceeași infrastructură care face deploy la microserviciile tale de producție gestionează și mentenanța repository-ului. Avantajul arhitectural suprem al GitHub Actions nu constă în faptul că are build agents mai rapizi sau un caching mai bun. Ci în faptul că elimină granița dintre workflow-ul developerului și sistemul de continuous integration. Dacă găsești aceste episoade utile și vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 2 din 14. Un workflow nu este doar un simplu script care rulează de sus în jos. Este un state machine paralelizat care îți distribuie codul pe mai multe mașini virtuale exact în același timp. Dacă îți scrii configurația așteptându-te la un proces continuu, datele tale vor dispărea la jumătatea drumului. Înțelegerea modelului mental de execuție previne asta. La cel mai înalt nivel se află workflow-ul. Acesta este un proces automat configurabil, definit într-un fișier YAML din interiorul repository-ului tău. El conține planul pentru ce ar trebui să se întâmple atunci când este declanșat. Un workflow în sine nu execută cod în mod direct. El orchestrează nivelul imediat următor. Un workflow conține unul sau mai multe job-uri. Aici sunt stabilite limitele fizice de execuție. Implicit, fiecare job dintr-un workflow rulează în paralel. Dacă definești un job de build și un job de test, GitHub pornește o mașină virtuală separată, numită runner, pentru fiecare job. Ele pornesc exact în același timp. Nu știu nimic una despre cealaltă. Job-ul de build rulează pe runner-ul A, iar job-ul de test rulează pe runner-ul B. Pentru că se execută pe mașini virtuale complet diferite, nu împart același filesystem, environment variables sau memorie. În interiorul unui job, modelul de execuție se schimbă complet. Un job este alcătuit dintr-o secvență de step-uri. În timp ce job-urile rulează în paralel pe mașini diferite, aceste step-uri rulează secvențial pe exact aceeași mașină. Step-ul unu se termină înainte să înceapă step-ul doi. Pentru că rulează pe același runner, aceste step-uri împart datele. În job-ul nostru de build, step-ul unu ar putea descărca codul aplicației tale. Step-ul doi îl compilează. Step-ul trei îl împachetează. Pentru că aceste step-uri au loc pe aceeași mașină virtuală, step-ul doi citește nativ fișierele descărcate de step-ul unu. Asta aduce în discuție un punct comun de confuzie. Oamenii confundă adesea step-urile cu action-urile. Un step nu este un action. Un step este pur și simplu o unitate de execuție în cadrul unui job. Este un slot în secvența ta. Poți umple acel slot în două moduri. Poți scrie un raw shell command, sau poți apela un action. Un action este un bloc de cod împachetat, reutilizabil, conceput pentru a efectua un task complex specific, cum ar fi configurarea unui environment pentru un limbaj de programare. Un action este payload-ul reutilizabil. Step-ul este container-ul care îl ține în secvența job-ului. Hai să ne uităm din nou la scenariul nostru de build și test. Workflow-ul începe. Doi runneri pornesc simultan. Pe runner-ul de build, step-urile se execută unul câte unul. Primul step apelează un checkout action pentru a face fetch la repository. Al doilea step rulează un shell command pentru a compila codul. Aceste step-uri împart spațiul de pe discul local fără probleme. Între timp, pe runner-ul de test, o secvență complet diferită de step-uri rulează în izolare. Dacă job-ul tău de test are nevoie de output-ul compilat de la job-ul de build, nu se poate uita pur și simplu pe hard disk. Job-ul de test este pe un server diferit. Iată ideea cheie. Limita unui job este limita fizică a mașinii virtuale, ceea ce înseamnă că scrierea unui workflow de GitHub Actions este de fapt un exercițiu de infrastructure mapping. Mersi că ai stat pe aici. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 3 din 14. Un singur commit automat primește push în repository-ul tău. Acel commit declanșează un workflow. Acel workflow face un alt commit, care declanșează din nou workflow-ul. În câteva minute, ai consumat sute de run minutes într-o buclă infinită accidentală. Modul prin care previi acest lucru și controlezi exact când se execută workflow-urile tale este prin triggere și filtre event-driven. Fiecare workflow GitHub Actions începe cu keyword-ul on. Asta îi spune lui GitHub ce evenimente ar trebui să-ți trezească workflow-ul. Poți specifica un singur eveniment, cum ar fi un push, sau mai multe evenimente într-un array. Dar evenimentele nu sunt mereu triggere simple. Unele evenimente, cum ar fi issue-urile sau pull request-urile, au mai multe tipuri de activitate. Când un issue este deschis, editat sau închis, declanșează același eveniment de bază. Dacă scrii pur și simplu că un workflow rulează pe issue-uri, va rula pentru toate acele activități. Ca să fii precis, specifici tipurile exacte de activitate. Îi poți spune lui GitHub să ruleze workflow-ul doar atunci când se deschide un issue, ignorând editările sau închiderile. Asta economisește run minutes și previne procesarea inutilă. Tipurile de activitate gestionează ce s-a întâmplat, dar filtrele de branch și path gestionează unde s-a întâmplat. Când declanșezi un workflow la un push sau pull request, de obicei nu vrei să ruleze pe fiecare branch în parte. Folosești filtre de branch pentru a viza destinații specifice, cum ar fi branch-ul main sau branch-urile de release. De asemenea, poți filtra după path-uri. Dacă un developer corectează un typo într-un fișier readme, nu este nevoie să rulezi întreaga suită de teste. Filtrele de path îți permit să incluzi sau să excluzi anumite fișiere și directoare. Iată informația cheie. Când combini filtre de path pozitive și negative, ordinea în care le scrii contează. Un filtru pozitiv îi spune workflow-ului să ruleze dacă un anumit path se modifică. Un filtru negativ, notat cu un semn de exclamare, îi spune workflow-ului să ignore modificările dintr-un path. GitHub le evaluează de sus în jos. Dacă pui un filtru negativ după un filtru pozitiv, filtrul negativ îl suprascrie pe cel pozitiv pentru orice fișiere care se potrivesc. Să punem asta în practică. Vrei să declanșezi un build de fiecare dată când codul primește push pe branch-ul main, dar vrei să economisești bani ignorând modificările care afectează doar documentația. Sub keyword-ul on, specifici evenimentul push. Sub acesta, definești un filtru de branch pentru main. Apoi, adaugi un filtru paths. Poți începe cu un filtru pozitiv pentru tot, folosind un wildcard. Chiar sub acesta, adaugi un filtru negativ pentru folderul docs, vizând în mod specific fișierele markdown. Dacă un commit modifică doar un fișier markdown din folderul docs, workflow-ul rămâne inactiv. Dacă un commit modifică un fișier python și un fișier markdown, workflow-ul rulează deoarece fișierul python declanșează filtrul pozitiv. Acum, înapoi la acea buclă infinită. Când workflow-ul tău rulează, GitHub oferă un credențial temporar numit GitHub Token pentru a se autentifica la repository. Prin design, orice evenimente declanșate folosind acest token specific nu vor crea noi workflow runs. Acesta este un mecanism de siguranță încorporat pentru a preveni buclele recursive. Totuși, dacă workflow-ul tău utilizează un Personal Access Token pentru a face commit la cod sau a face push la tag-uri, acea plasă de siguranță dispare. Noul commit va declanșa un alt workflow run, care va face un alt commit, creând o buclă infinită. Dacă trebuie să utilizezi un Personal Access Token, trebuie să fii extrem de disciplinat cu filtrele tale de branch și path pentru a te asigura că acel commit automat nu îndeplinește condițiile de trigger pentru workflow. Cel mai eficient mod de a-ți optimiza costurile de calcul nu este să scrii cod mai rapid, ci pur și simplu să te asiguri că workflow-urile tale rulează doar atunci când este absolut necesar. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 4 din 14. Încerci să folosești o variabilă de mediu de pe runner pentru a dicta dacă un job ar trebui să pornească, iar pipeline-ul tău pică înainte măcar să pornească o mașină. Ești sigur că variabila există, dar GitHub se comportă ca și cum ar fi goală. Problema nu e variabila ta, ci timing-ul. Ca să rezolvăm asta, trebuie să vorbim despre evaluarea stării cu variabile și contexte. În GitHub Actions, starea workflow-ului tău este evaluată în două faze complet separate, care au loc în două locuri complet diferite. Asta e diferența principală dintre un context și o variabilă de mediu. Hai să ne uităm mai întâi la contexte. Contextele sunt colecții de informații evaluate direct de GitHub, înainte ca workflow-ul tău să fie măcar trimis către un runner. Ele conțin date despre rularea workflow-ului, repository, evenimentul de webhook care a declanșat rularea și userul care a inițiat-o. Pentru că GitHub evaluează contextele imediat, le poți folosi ca să controlezi structura pipeline-ului tău. Accesezi un context folosind o sintaxă specifică de expresie, de obicei un semn de dolar urmat de acolade duble care conțin numele contextului. Pe de altă parte, variabilele de mediu default sunt evaluate mai târziu, chiar pe mașina de runner care îți execută jobul. Când runner-ul pornește, setează automat mai multe variabile de mediu default, cum ar fi numele de repository sau branch-ul curent. Le accesezi exact așa cum ai face-o într-un script normal de bash sau PowerShell. De asemenea, poți să-ți definești propriile variabile de mediu folosind cheia env în fișierul tău de workflow. Poți atașa cheia env la un workflow întreg, la un singur job sau la un step specific. Aici e ideea de bază. Ciclul de viață dictează ce poți folosi și unde. O greșeală comună e să încerci să folosești o variabilă de mediu de runner în interiorul unui condițional if la nivel de job. Dacă îi spui unui job să ruleze doar dacă o anumită variabilă de mediu de bash este egală cu o anumită valoare, workflow-ul va pica. Runner-ul nu a pornit încă. Mașina nu există, deci nici variabila de mediu nu există. Ca să iei decizii înainte să pornească runner-ul, trebuie să folosești un context. Hai să ne uităm la un scenariu practic. Vrei ca un job de deploy să ruleze doar dacă codul este dat merge în branch-ul main. La nivel de job, scrii un condițional if. Folosești expresia de context ca să verifici dacă contextul github dot ref este egal cu string-ul refs slash heads slash main. GitHub evaluează asta instant. Dacă este adevărat, GitHub alocă un runner și trimite jobul către el. Odată ce jobul ajunge pe runner și step-urile tale încep să se execute, treci la variabile de mediu. În interiorul unui step de script bash din același job, s-ar putea să ai nevoie să știi numele branch-ului ca să pui un tag pe un build artifact. Aici, pur și simplu tastezi un semn de dolar urmat de GITHUB underscore REF. Runner-ul citește asta din mediul local al sistemului său de operare. Faci referire la exact aceeași informație, numele branch-ului, dar o accesezi prin mecanisme complet diferite, în funcție de locul unde se află execuția în acel moment. Contextele rutează workflow-ul pe serverele GitHub. Variabilele de mediu controlează scripturile de execuție pe runner. Dacă te lupți vreodată cu variabile goale în logica de workflow, întreabă-te dacă mașina care evaluează acea logică a apucat măcar să pornească. Ca întotdeauna, mulțumesc că m-ai ascultat. Ne vedem în următorul episod.

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 5 din 14. Dezvoltatorii generează adesea Personal Access Tokens cu durată lungă de viață pentru task-uri de bază din repository, lăsând credențiale permanente în codebase-ul lor. Dar pentru majoritatea interacțiunilor cu GitHub, nu ai nevoie să creezi un token deloc - există un token securizat și efemer care te așteaptă în fiecare job. Acesta este focusul episodului de astăzi: Granița de securitate: Secrets și GITHUB_TOKEN. Când declanșezi un workflow, GitHub provizionează automat un secret unic numit GITHUB_TOKEN. Acesta nu este un Personal Access Token standard. Funcționează ca un installation access token de scurtă durată pentru un GitHub App. Există exclusiv pe durata job-ului din workflow. În momentul în care job-ul se termină, sau după maximum 24 de ore, token-ul expiră și devine complet inutil. O greșeală comună este generarea unui Personal Access Token permanent doar pentru ca un workflow să adauge un label la un issue sau să lase un comentariu la un pull request. Asta îți extinde attack surface-ul în mod inutil. GITHUB_TOKEN-ul built-in are deja permisiunile necesare pentru a interacționa cu repository-ul care a declanșat workflow-ul. Dacă job-ul tău trebuie să adauge un label la un issue, pasezi acest token built-in către step-ul care execută apelul API. Niciun credențial permanent nu este vreodată creat, stocat sau expus. Asta acoperă interacțiunea cu GitHub în sine. Dar workflow-ul tău va trebui inevitabil să comunice cu lumea exterioară. Aici intră în scenă secrets-urile criptate custom. Când creezi un secret custom, acesta nu stă în plain text pe un server GitHub. Valoarea este criptată local folosind un sealed box Libsodium înainte de a fi măcar transmisă. Criptarea se bazează pe criptografia cu cheie publică. Când adaugi un secret prin interfața web sau prin API, GitHub îți oferă o cheie publică. Clientul tău folosește acea cheie pentru a sigila box-ul. Doar mașina virtuală izolată a runner-ului deține cheia privată corespunzătoare necesară pentru a deschide acel box, și decriptează payload-ul doar în momentul exact în care job-ul se execută. Poți defini aceste secrets criptate la diferite niveluri, în funcție de arhitectura ta. Secrets-urile la nivel de repository se aplică unui singur codebase. Secrets-urile la nivel de organizație îți permit să partajezi un singur credențial, cum ar fi o parolă pentru baza de date de producție, în mai multe repository-uri. Asta centralizează managementul credențialelor, dar necesită un control strict. Secrets-urile la nivel de organizație folosesc access policies unde definești explicit care repository-uri au permisiunea să citească secretul. Să aplicăm asta pe un scenariu concret. Să zicem că ai o parolă de bază de date la nivel de organizație, necesară pentru un step de migrare a bazei de date. Nu vrei ca această parolă să fie accesibilă întregului workflow. GitHub Actions impune o graniță strictă de securitate aici. Secrets-urile nu sunt injectate automat în environment-ul fiecărui step. Trebuie să mapezi explicit secretul la un environment variable în step-ul specific care are nevoie de el. Când scrii fișierul de workflow, accesezi valoarea criptată folosind o referință de context specifică, apelând-o din obiectul secrets, și o atribui unui environment variable local. Pentru că ai mapat-o explicit, step-ul dinaintea migrării nu poate vedea parola, iar step-ul de după nu poate vedea parola. Iată ideea cheie. Securitatea în automatizare înseamnă minimizarea duratei de viață și limitarea scope-ului. Bazează-te pe GITHUB_TOKEN-ul efemer pentru acțiunile interne din repository pentru a evita managementul credențialelor permanente, și mapează strict secrets-urile criptate doar la step-urile individuale care necesită acces extern. Asta e tot pentru acest episod. Pe data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 6 din 14. Setezi un workflow cu mai multe job-uri și, ca să te asiguri că al doilea job are tot ce îi trebuie, împachetezi întregul folder de dependințe și îl dai mai departe. Dar, dintr-o dată, build-ul tău durează cu cinci minute mai mult, iar consumul de storage explodează. Problema este o confuzie fundamentală între două mecanisme distincte de date, și exact despre asta vorbim în acest episod: Optimizarea datelor: Caching vs Artifacts. O să clarificăm confuzia imediat. Caching-ul și artifacts mută fișiere între runnerii tăi de GitHub Actions, dar rezolvă probleme complet diferite. Gândește-te la artifacts ca la ceea ce produce workflow-ul tău. Gândește-te la caching ca la ceea ce consumă workflow-ul tău. Dacă inversezi aceste roluri, vei crea un bottleneck silențios pentru întregul tău pipeline. Artifacts sunt fișiere generate pe care vrei să le păstrezi după ce un job se termină. Poate fi vorba de un binar compilat, un raport de test coverage, sau o arhivă zip a directorului tău final de build. Ele există din două motive principale. În primul rând, ca să poți descărca output-ul final al workflow-ului tău după ce se termină. În al doilea rând, pentru a pasa datele generate între diferite job-uri din cadrul aceluiași workflow run. Pentru că fiecare job rulează pe o mașină virtuală nouă, orice fișiere create în job-ul unu se pierd instantaneu când acel job se termină, asta dacă nu le faci upload explicit. Folosind acțiunea de upload artifact, salvezi acele fișiere în storage-ul GitHub. Apoi, job-ul doi folosește acțiunea de download artifact pentru a le trage în propriul său workspace curat. Acum, compară asta cu dependency caching. Caching-ul este pur și simplu o optimizare de performanță concepută pentru a-ți accelera workflow-ul de-a lungul diferitelor rulări în timp. Când faci un build de software, de obicei descarci mii de dependințe third-party, cum ar fi pachete din NPM sau pip. Să le faci fetch prin rețea la fiecare rulare este lent. În loc să descarci dependințe noi de fiecare dată, acțiunea de cache îți salvează folderul de dependințe descărcat pe serverele de cache. Atribuie acestui cache o cheie unică, aproape întotdeauna bazată pe hash-ul lock file-ului tău. La rularea workflow-ului de mâine, GitHub verifică dacă lock file-ul se potrivește cu o cheie existentă. Dacă se potrivește, restaurează folderul direct în runner-ul tău în câteva secunde, ocolind complet package registry-ul. Iată ideea cheie. Cea mai mare greșeală pe care o poți face este să folosești acțiunea de upload artifact pentru a muta un folder masiv de dependințe, cum ar fi node modules, între job-uri. Artifacts procesează datele făcând zip, upload, download și unzip. Să faci asta cu zeci de mii de fișiere text minuscule adaugă o latență de rețea masivă la run time-ul tău și îți consumă din cotele de storage ale contului. Artifacts nu sunt construite pentru viteză brută; ele sunt construite pentru transfer sigur de date și păstrare permanentă. Cache-urile, pe de altă parte, sunt extrem de optimizate pentru a face pull rapid la dependency trees grele, și expiră și se șterg automat pentru a economisi spațiu. Imaginează-ți un pipeline bine structurat care le folosește corect pe amândouă. Ai un workflow cu un build job și un deploy job. În build job, primul tău pas folosește acțiunea de cache pentru a restaura instantaneu dependințele NPM din rularea de ieri. Codul tău se compilează rapid, producând un binar final al aplicației. Apoi folosești acțiunea de upload artifact pentru a salva doar acel singur fișier binar. Build job-ul se termină, iar runner-ul este distrus. Deploy job-ul pornește pe un nou runner. Nu are nevoie de cache și nu are nevoie de dependințele NPM. Folosește doar acțiunea de download artifact pentru a prelua binarul compilat pe care tocmai l-ai construit, și apoi îi face push pe serverul tău de producție. Caching-ul este o scurtătură de unică folosință pentru lucrurile pe care le descarci, în timp ce artifacts sunt transferul esențial pentru lucrurile pe care le creezi. Mulțumesc că ai stat cu noi. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 7 din 14. Un developer dă push la trei commit-uri rapide pe un pull request deschis, în cinci minute. Dacă serverul tău de CI rulează trei test suites redundante, arzi bani. Ai nevoie de o modalitate să-i spui sistemului că doar cel mai recent cod contează, și exact de asta se ocupă controlul flow-ului prin concurrency. By default, GitHub Actions rulează workflow-urile declanșate în paralel. Dacă dai push de cinci ori, pornește cinci runners independenți. Pentru verificări de bază, asta irosește minute de runner. Pentru deployments, este de-a dreptul periculos. Dacă două rulări ale unui workflow încearcă să dea deploy simultan pe același mediu de staging, creezi un race condition. Commit-ul mai vechi ar putea chiar să termine deployment-ul după cel mai nou, suprascriind update-urile și lăsând mediul într-o stare outdated. Rezolvi asta folosind keyword-ul concurrency. Îl poți aplica la nivel de top pe întregul workflow sau îl poți restricționa la un anumit job. Mecanismul se bazează în întregime pe concurrency groups. Un concurrency group este doar un string pe care îl definești. Dacă două rulări au exact același nume de grup, GitHub impune limite de concurrency între ele. Mulți fac greșeala să hardcodeze acest string. Dacă setezi numele grupului doar la cuvântul deploy, atunci un push pe branch-ul de testing va anula un deployment activ pe branch-ul principal de producție. Numele grupului trebuie să fie dinamic. Îl construiești folosind variabile de context, cum ar fi referința branch-ului curent. Dacă denumești grupul folosind numărul de pull request, atunci limitele de concurrency se aplică doar la push-urile din acel pull request specific. Branch-ul tău main rămâne complet neafectat. Când este declanșat un nou workflow, GitHub verifică dacă o rulare este deja activă pentru acel concurrency group. Dacă există, comportamentul default este să plaseze noua rulare într-o stare de pending. Așteaptă într-un queue. Aici e ideea principală. Queue-ul ține un singur job în pending. Dacă o a treia rulare este declanșată în timp ce prima rulează și a doua este în pending, a doua rulare este scoasă din queue. Doar cea mai recentă rulare ajunge să aștepte. Așteptarea este mai sigură pentru deployments, dar pentru testarea de pull requests, așteptarea tot consumă timp inutil. Aici intervine setarea cancel-in-progress. Este un flag boolean pe care îl adaugi sub definiția de concurrency group. Când setezi cancel-in-progress pe true, schimbi comportamentul din queuing în terminating. Întoarce-te la developer-ul care dă push la trei commit-uri rapide. Primul push declanșează un test suite. Două minute mai târziu, dă push din nou. Pentru că ai setat concurrency group pe numele branch-ului și ai activat cancel-in-progress, GitHub vede noua rulare, oprește instant test suite-ul activ pentru primul commit și începe testarea celui de-al doilea commit. Când are loc al treilea push un minut mai târziu, oprește a doua rulare și o începe pe a treia. Developer-ul tot primește acel pass sau fail final, dar tu ai plătit pentru execuția testelor o singură dată. Controalele de concurrency îți transformă pipeline-urile de CI dintr-un sistem reactiv, care execută orbește fiecare trigger, într-un sistem state-aware, care consumă resurse doar pe codul care contează cu adevărat. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 8 din 14. Credențialele bazei de date de production nu ar trebui să fie niciodată accesibile unui pull request random de pe un feature branch. Totuși, dacă toate secrets-urile tale sunt stocate la nivel de repository, orice workflow le poate accesa. Rezolvarea acestei breșe de securitate este exact motivul pentru care ai nevoie de Gating Deployments with Environments. În primul rând, trebuie să clarificăm o confuzie frecventă. Un environment în GitHub Actions nu este un server fizic. GitHub nu îți pornește o mașină virtuală sau o instanță de cloud numită production. Un environment este pur și simplu o graniță logică configurată în setările repository-ului tău de pe GitHub. Acționează ca un gatekeeper, controlând când un job are voie să ruleze și ce date are voie să vadă acel job. Motivul principal pentru care există acest feature este pentru a asigura release governance și a proteja datele sensibile. Când creezi un environment, îi poți atașa direct secrets și variabile specifice. Ai putea crea un environment numit staging și un altul numit production. Fiecare primește propriul set unic de API keys, stocate sub exact același nume de variabilă. În fișierul de workflow, legi un anumit job de un environment pur și simplu trecându-i numele. Când rulează workflow-ul, jobul care face referire la environment-ul de staging primește cheile de staging. Jobul care face referire la environment-ul de production primește cheile de live. Asta îți izolează complet datele sensibile. Un job care rulează pe un feature branch nu poate citi cheile de production, deoarece nu rulează în contextul environment-ului de production. Dar izolarea de secrets este doar jumătate din puterea environment-urilor. Cealaltă jumătate o reprezintă protection rules. Aceste reguli acționează ca niște porți stricte în pipeline-ul tău de deployment. Cea mai comună protection rule este un required reviewer. Hai să vedem cum funcționează asta într-un scenariu real. Ai un workflow care îți face build la aplicație și îi face deploy automat pe staging. Acel job se termină cu succes. Imediat următorul job din workflow este configurat să facă deploy în production și face referire la environment-ul tău de production. Dacă ai o regulă de required reviewer setată pentru acel environment, workflow-ul se oprește fix acolo. Jobul este pus pe pauză. Nu este trimis către un runner, iar API keys de production rămân blocate în siguranță. GitHub trimite o notificare managerului sau echipei desemnate, indicând faptul că un deployment este în așteptare. Workflow-ul va rămâne în această stare de pending până când se ia o măsură. Doar atunci când managerul dă click pe approve în interfața GitHub, se deschide poarta. Exact în acel moment, jobul este trimis către un runner disponibil, secrets-urile de production sunt decriptate și injectate, iar scriptul de deployment se execută. Poți adăuga și alte protection rules peste aprobările manuale. O opțiune este un wait timer, care forțează un job să întârzie un număr specificat de minute înainte să înceapă. Asta îți oferă un buffer ca să anulezi un rollout dacă observi un spike în ratele de eroare pe dashboard-urile tale de monitorizare imediat după un deployment pe staging. De asemenea, poți configura deployment branches. Asta restricționează environment-ul astfel încât să accepte doar joburi care rulează de pe anumite branch-uri, cum ar fi main branch-ul tău sau anumite release tags. Dacă un developer încearcă să forțeze un deployment job în production de pe un bugfix branch random, poarta environment-ului pur și simplu respinge rularea. Iată ideea principală. Environment-urile decuplează mecanica de deployment de access control. Fișierul tău de workflow descrie pașii exacți necesari pentru a face deploy la cod, dar setările de environment din GitHub dictează cine are autoritatea să permită acest lucru și ce secrets sunt deblocate atunci când o fac. Dacă îți plac aceste deep dive-uri tehnice, poți susține emisiunea căutând DevStoriesEU pe Patreon. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 9 din 14. Cel mai sigur credențial de cloud este cel care expiră la cinci minute după ce se termină deploy-ul. Cu toate astea, multe echipe încă copiază chei de administrator long-lived în setările repository-ului, sperând că nu vor face niciodată leak. Astăzi rezolvăm asta uitându-ne la Passwordless Cloud Access prin OIDC. Istoric vorbind, conectarea unui workflow GitHub la un cloud provider însemna generarea unei chei de acces în AWS, Google Cloud sau Azure și salvarea ei ca un GitHub Secret long-lived. Dacă acel secret făcea leak, oricine îl putea folosi de oriunde până când un administrator îl revoca manual. Lumea crede adesea că OpenID Connect, sau OIDC, este doar un nou tip de secret căruia îi dai paste în repository-ul tău. Nu este. OIDC înlocuiește complet secretele stocate. Este un protocol care generează un token criptografic dinamic, on the fly, pentru a dovedi identitatea workflow-ului către cloud provider-ul tău. GitHub acționează ca un Identity Provider OIDC. Când un workflow rulează, poate cere GitHub să emită un JSON Web Token, sau JWT. Ca să faci asta, trebuie să adaugi o permisiune specifică în fișierul tău de workflow. Setezi blocul permissions pentru a permite write access pentru ID token. Asta îi spune lui GitHub că workflow-ul este autorizat să genereze un credențial de identitate. Iată ideea de bază. Acest token nu acordă acces prin el însuși. Este pur și simplu un document semnat digital care conține claims. Aceste claims sunt bucăți de metadata care declară fapte verificabile despre workflow-ul care rulează în prezent. Token-ul include numele repository-ului, organizația, branch-ul, environment-ul și evenimentul care a declanșat run-ul. Pentru că GitHub semnează criptografic token-ul, cloud provider-ul tău poate avea încredere în aceste claims. Asta formează fundația unui deployment zero-trust. Hai să ne uităm la un job de deploy care face push la o imagine într-un AWS Elastic Container Registry. Workflow-ul pornește și cere un token OIDC de la GitHub. Token-ul este generat, conținând claims care verifică faptul că provine din branch-ul main al repository-ului tău de backend. Workflow-ul trimite apoi acest token către AWS. AWS verifică mai întâi semnătura digitală pentru a se asigura că token-ul provine, de fapt, de la GitHub. Apoi, citește aceste claims. Verifică aceste claims în raport cu un trust policy strict pe care l-ai definit anterior. Policy-ul ar putea spune că acceptă token-uri doar din repository-ul tău specific și numai dacă workflow-ul rulează pe branch-ul main. Pentru că aceste claims se potrivesc, AWS acceptă token-ul. AWS nu returnează o cheie permanentă. În schimb, emite un access token temporar. Acest token ar putea fi valabil doar cincisprezece minute. Workflow-ul tău folosește acest credențial temporar pentru a face push la imaginea de container în registry. Când job-ul se termină, credențialul expiră. Nu există nimic de făcut rotate și nimic stocat în GitHub pe care un atacator l-ar putea extrage. Când configurezi asta, acordă o atenție deosebită la subject claim, adesea numit sub claim. Acesta este câmpul principal pe care cloud providerii îl folosesc pentru a filtra accesul. By default, GitHub formatează subject claim-ul pentru a include numele repository-ului și git reference-ul, cum ar fi branch-ul sau tag-ul. Trebuie să te asiguri că trust policy-ul tău de cloud validează strict acest subject claim. Dacă verifici doar numele organizației, orice repository din organizația ta ar putea solicita resurse de cloud. Prin legarea accesului temporar de cloud la metadata specifice workflow-ului, garantezi că un repository compromis nu îți poate atinge infrastructura decât dacă cererea vine exact din branch-ul și environment-ul în care ai încredere în mod explicit. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 10 din 14. Când gestionezi continuous integration pe cincizeci de repository-uri, să dai copy și paste la exact același YAML este un coșmar de mentenanță care abia așteaptă să se întâmple. Schimbi un tool de security scanning și, dintr-o dată, trebuie să updatezi manual cincizeci de fișiere separate. Acest episod este despre scalarea DRY pipelines pentru a rezolva exact asta. Ca să nu te mai repeți în GitHub Actions, ai două tool-uri principale. Reusable Workflows și Composite Actions. Inginerii o aleg frecvent pe cea greșită, pentru că ambele evită duplicarea. O Composite Action nu este un workflow. Este pur și simplu un pachet de steps. Un Reusable Workflow este un pipeline complet care grupează job-uri întregi. Dacă logica ta shared trebuie să se întindă pe mai multe mașini, să orchestreze dependențe complexe între job-uri sau să gestioneze secrets în siguranță, trebuie să folosești un Reusable Workflow. O Composite Action ia o secvență de steps, cum ar fi checkout pe cod, setarea unui environment pentru limbaj și instalarea de dependencies, și le împachetează într-o singură custom action. Când un workflow folosește această acțiune, toți acei steps grupați se execută secvențial în interiorul job-ului curent existent. Composite Action-ul nu decide pe ce runner se execută. Rulează oriunde îl plasează job-ul părinte. Există pur și simplu pentru a curăța logica repetitivă a steps-urilor într-un singur execution environment. Reusable Workflows operează la un nivel arhitectural mult mai înalt. Sunt fișiere YAML complete cărora un alt workflow le poate da trigger. Workflow-ul care face request-ul este caller workflow, iar workflow-ul care primește trigger este called workflow. Pentru că un called workflow definește job-uri întregi, el controlează infrastructura. Un job din interiorul unui Reusable Workflow ar putea rula pe un runner de Ubuntu pentru a face build la o aplicație, în timp ce un job dependent rulează pe un runner de macOS pentru a o testa. Gândește-te la o echipă de Platform Engineering care standardizează un deployment pipeline pentru Node. Ei vor să se asigure că fiecare echipă rulează security checks identice înainte de a face ship la cod. În loc să se bazeze pe cincizeci de echipe de produs ca să mențină fișiere YAML identice, inginerii de platformă creează un singur Reusable Workflow central într-un shared repository. Acest fișier central definește secvența exactă de job-uri necesare pentru a scana, a face build și a da deploy la aplicație. Cele cincizeci de repository-uri de produs creează apoi un caller workflow minimal. Acest caller workflow conține un singur job care pointează direct către fișierul shared al echipei de platformă, folosind path-ul său. Transmiți datele de configurare către called workflow folosind inputs, specificând parametri precum numele de target environment sau versiunea de Node. Caller workflow-ul poate, de asemenea, să transmită secrets. Poți mapa explicit anumite secrets, sau poți instrui called workflow-ul să moștenească pur și simplu toate secrets disponibile pentru caller. Când echipa de platformă trebuie să rotească un deployment secret sau să adauge un nou tool de static analysis, ei updatează called workflow-ul central. Instant, toate cele cincizeci de repository-uri rulează noul security check la următorul lor commit. Echipele de produs nu ating nicio configurație. Iată ideea de bază. Folosește Composite Actions pentru a ascunde logica dezordonată a steps-urilor într-un singur environment, dar folosește Reusable Workflows pentru a impune arhitecturi standardizate de pipeline în întreaga organizație. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 11 din 14. Un container garantează versiuni exacte ale tool-urilor, dar vine cu un cost de latență ascuns la fiecare rulare a unui workflow. Consistența mediului tău ar putea să-ți încetinească echipa și să o blocheze într-un singur sistem de operare fără ca măcar să-ți dai seama. Crearea de custom actions: Docker vs JavaScript rezolvă această tensiune. Un custom action este o logică reutilizabilă pe care o scrii o singură dată și o distribui în mai multe repository-uri. Când construiești unul, trebuie să alegi o arhitectură de execuție. Cele două modele principale sunt JavaScript și Docker. Mulți ingineri aleg by default Docker actions pentru că vor siguranță absolută și dependențe predictibile. Ei presupun că un container este cea mai robustă alegere. Realitatea este că, dacă construiești un Docker action, blochezi permanent orice runner de macOS sau Windows să-ți folosească tool-ul. Docker actions se execută doar în medii Linux. JavaScript actions au o abordare diferită. Se execută direct pe host machine. Îți scrii logica, o compilezi într-un singur fișier cu toate dependențele și pui metadata action-ului să pointeze către acel entry file. Când se face trigger la un workflow, runner-ul folosește Node runtime-ul built-in pentru a-ți executa scriptul. Asta îți decuplează logica de sistemul de operare de dedesubt. Exact același action va rula nativ pe runneri de Linux, macOS și Windows, fără modificări. Docker container actions, în schimb, împachetează sistemul de operare, dependențele de sistem și codul tău împreună, într-o unitate imutabilă. Tu dictezi exact mediul. Runner-ul citește un Dockerfile oferit de action-ul tău, dă build sau pull la imaginea de container și îți rulează codul în acel spațiu izolat. Aici e ideea cheie. Izolarea strictă a unui Docker action introduce o penalizare de cold-start. Gândește-te la o echipă care construiește un tool custom de code linting pentru a-l folosi în toată organizația. Dacă îl construiesc ca un Docker action, runner-ul trebuie să dea pull la acea imagine de container înainte să poată evalua o singură linie de cod. Asta ar putea adăuga o întârziere de cincisprezece secunde la începutul fiecărui job de linting. La sute de pull requests pe zi, acel idle time se adună în ore de compute irosit. Dacă echipa construiește aceeași logică de linting în JavaScript, runner-ul pur și simplu descarcă fișierul script și îl execută instant. Alegerea arhitecturii dictează modul în care action-ul tău se comportă în mediul real. Dacă tool-ul tău se bazează pe binare de sistem complexe, necesită o versiune foarte specifică a unui compiler sau face wrap la Bash scripts legacy care sunt fragile în afara unei anumite distribuții de Linux, Docker este alegerea corectă. Plătești taxa de latență în schimbul stabilității garantate. Dacă obiectivul tău este să construiești un tool rapid, adoptat pe scară largă, care funcționează pe orice tip de proiect, JavaScript este calea mai bună. Alegerea arhitecturală dintre Docker și JavaScript pentru un custom action nu este niciodată despre limbajul de programare în care preferi să scrii, ci este un trade-off dificil între controlul strict al mediului și viteza de execuție cross-platform. Asta e tot pentru episodul ăsta. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 12 din 14. Runnerele cloud GitHub sunt extrem de convenabile, până când testele de integrare trebuie să acceseze o bază de date legacy, ascunsă în siguranță în spatele unui firewall corporate. Dintr-o dată, un runner public nu mai poate accesa datele tale private. Exact aici intervine Fleet Management: Hosted vs Self-Hosted Runners. By default, GitHub Actions utilizează runnere GitHub-hosted. Când se declanșează un workflow, GitHub ridică o mașină virtuală nouă. Poți cere Ubuntu, Windows sau macOS. Runner-ul execută job-ul tău, raportează rezultatul, iar apoi mașina virtuală este distrusă imediat. Ai un mediu complet curat de fiecare dată. Nu gestionezi sistemul de operare, nu instalezi patch-uri de securitate și nu îți faci griji pentru fișierele rămase de la un build anterior. Totuși, această izolare este o sabie cu două tăișuri. Pentru că aceste runnere există în infrastructura de cloud GitHub, ele operează cu adrese IP dinamice și nu au acces direct la rețelele tale private. Dacă ai o aplicație internă sau o bază de date care nu poate fi expusă pe internetul public, ai nevoie de un runner care să stea în interiorul propriului tău perimetru de securitate. Acesta este un self-hosted runner. Tu asiguri hardware-ul. Poate fi un server fizic într-un data center, o mașină virtuală la cloud provider-ul tău sau un container. Instalezi aplicația de runner GitHub Actions pe acea mașină. Runner-ul se conectează în exterior către GitHub, preia job-urile în așteptare, le rulează local și trimite log-urile înapoi. Pentru că se află în rețeaua ta, poate comunica în siguranță cu infrastructura ta internă fără să dea găuri în firewall. Iată ideea cheie. Tu deții hardware-ul, ceea ce înseamnă că tu te ocupi de mentenanță. Ești responsabil pentru actualizările sistemului de operare, securitatea rețelei și instalarea dependențelor necesare, cum ar fi language runtimes sau build tools. O concepție greșită des întâlnită este că runnerele self-hosted se comportă exact ca cele hosted. Nu este așa. Runnerele GitHub-hosted sunt efemere by design. Runnerele standard self-hosted sunt stateful. Când un job se termină pe un self-hosted runner default, mașina rămâne pornită. Dacă job-ul tău scrie un fișier temporar, pornește un proces în background sau face pull la o imagine mare de container, toate acestea rămân pe disc când pornește următorul job. Acest lucru creează riscuri serioase de cross-contamination. Un build script defect dintr-un pull request ar putea lăsa în urmă fișiere corupte, provocând eșecul job-ului de deploy care rulează imediat după. Trebuie să îți configurezi activ infrastructura self-hosted pentru a fi efemeră dacă asta îți dorești, adesea folosind webhook-uri pentru a ridica noi containere per job. Dacă ai nevoie pur și simplu de mai multă putere de procesare sau de o adresă IP statică, dar totuși vrei ca GitHub să se ocupe de mentenanța mașinii, există o cale de mijloc numită larger runners. Acestea sunt mașini GitHub-hosted unde tu definești specificațiile hardware și caracteristicile de rețea, dar ele rămân efemere și gestionate de GitHub. În cele din urmă, decizia dintre hosted și self-hosted este rareori doar despre costurile de compute. Este un trade-off fundamental între confortul unui mediu zero-maintenance, disposable, și necesitatea de a-ți controla propriile limite de rețea. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 13 din 14. Ai o echipă imensă și, la nouă dimineața, o sută de developeri dau push la cod simultan. Serverele tale statice de build fie se îneacă în queue, fie le-ai făcut over-provisioning și stau degeaba, irosind resurse scumpe de compute toată noaptea. Kubernetes Scale: Actions Runner Controller rezolvă asta transformând pipeline-ul tău de build într-un sistem dinamic, container-native. Runnerele standard self-hosted sunt de obicei mașini virtuale statice sau containere long-lived. Le configurezi, le înregistrezi într-un repository și stau acolo și fac polling după task-uri. Setup-ul ăsta garantează că plătești pentru idle time, iar când lovește un spike brusc de build-uri, queue-ul tău pur și simplu se umple până când un runner existent își termină task-ul curent. Actions Runner Controller, sau ARC, schimbă fundamental acest model. ARC este un operator Kubernetes care orchestrează runner scale sets cu auto-scaling. În loc să mențină worker nodes long-lived, face provision la runnere efemere, Just-in-Time, bazat pe dimensiunea exactă a queue-ului tău. Ca să reușească asta fără să lovească în API rate limits, ARC se bazează pe două componente arhitecturale principale din interiorul clusterului tău Kubernetes. Prima este pod-ul Listener. Listener-ul folosește un HTTPS long poll pentru a se conecta la GitHub. În loc să îți ceară să deschizi inbound firewall ports ca să primești webhook-uri, Listener-ul contactează GitHub și ține conexiunea deschisă. Stă acolo liniștit, așteptând ca GitHub să îi trimită un mesaj de Job Available. Când Listener-ul primește acel mesaj, dă informația mai departe către pod-ul Controller. Controller-ul acționează ca un provisioning engine. Comunică imediat cu Kubernetes API ca să dea spin up unui runner pod complet nou, special pentru acel singur pending job. Acest pod este un runner efemer Just-in-Time. Dă boot, primește un registration token short-lived, execută workflow-ul, și apoi își dă terminate imediat. Hai să ne întoarcem la acel code rush de la nouă dimineața. O sută de developeri dau push la commit-uri exact în același timp. Pod-ul Listener detectează valul brusc de mesaje Job Available de la GitHub. Alertează Controller-ul, care cere instant o sută de Kubernetes pods efemere. Clusterul tău face scale out, alocând noduri dacă e nevoie, iar job-urile se execută în paralel. Pe măsură ce fiecare workflow se termină, pod-ul lui este complet distrus. Până la nouă și un sfert, queue-ul este gol, iar numărul tău de runnere face scale back la zero. Ai folosit compute paralel masiv timp de exact cincisprezece minute, iar apoi ai încetat să mai plătești pentru el. Aici e ideea principală. Pentru că fiecare job rulează într-un pod izolat, freshly provisioned, care este distrus imediat după execuție, elimini complet state contamination între build-uri. Un dirty cache, un background process rămas, sau o environment variable modificată de la un run anterior pur și simplu nu îl pot strica pe următorul. Câștigi securitatea unui build environment curat de fiecare dată, combinată cu eficiența exactă de compute a Kubernetes auto-scaling. Adevărata valoare a Actions Runner Controller este că te oprește din a trata runnerele de continuous integration ca pe o infrastructură grea pe care trebuie să o menții, transformându-le în schimb în compute pur tranzitoriu care există doar cât timp un job rulează activ. Mersi că ai petrecut câteva minute cu mine. Până data viitoare, toate bune.

Salut, sunt Alex de la DEV STORIES DOT EU. GitHub Actions, episodul 14 din 14. Un utilizator îți descarcă acel command line tool compilat de pe o pagină de release. Dacă un dependency compromis sau un actor rău intenționat a schimbat acel binary după ce a primit build, o verificare standard de checksum nu îl va salva. Hash-urile standard dovedesc doar că fișierul descărcat se potrivește cu fișierul găzduit, nu de unde provine el de fapt. Pentru a garanta că un fișier a fost generat exact de codul tău, ai nevoie de Supply Chain Integrity cu Attestations. Un attestation nu este doar un build log sau un fișier text care conține un hash lăsat lângă release-ul tău. Este o afirmație semnată criptografic, nefalsificabilă, despre proveniența unui artifact. Îți leagă acel binary final direct de commit SHA-ul exact, de acel workflow run specific și de identitatea OpenID Connect a mediului de build. Procesul are loc în întregime în cadrul acelui workflow GitHub Actions al tău. După ce codul tău se compilează, folosești acțiunea oficială de build provenance. Această acțiune calculează acel checksum al artifact-ului tău finalizat și contactează o autoritate centralizată de semnare, mai exact Sigstore. Acel workflow își schimbă token-ul OpenID Connect temporar, specific acelui job, cu un certificat de semnare de scurtă durată. Pentru că acest token este generat de GitHub Actions și mapat direct la repository-ul tău, el acționează ca o carte de identitate nefalsificabilă pentru acel workflow runner. Această interacțiune generează o înregistrare criptografică permanentă. Această înregistrare afirmă fără echivoc că acest hash de fișier exact a fost produs de repository-ul tău, declanșat de un commit specific, în timpul unui workflow run specific. Semnătura este atașată la artifact, creând un pachet de dovezi care călătorește cu fișierul oriunde ajunge să fie găzduit. Iată ideea principală. Adevărata valoare de securitate se vede pe partea de consumer. Când un utilizator îți descarcă acel command line tool, nu trebuie să aibă încredere orbește în provider-ul de hosting sau în acel download mirror. Înainte să execute acel binary, folosește GitHub CLI pentru a verifica acel attestation la nivel local. Rulează o comandă de attestation verify pe executabilul descărcat, specificând explicit owner-ul repository-ului tău ca sursă așteptată. CLI-ul inspectează semnătura criptografică și o verifică în acel public transparency log. Dacă semnătura este validă, dovedește matematic că fișierul a fost compilat de acel workflow oficial al tău. Dacă un actor rău intenționat a interceptat descărcarea, a modificat compilarea sau a înlocuit acel binary pe pagina de release, verificarea eșuează instantaneu. Semnătura nu poate fi falsificată pentru că atacatorul nu poate deține niciodată acel identity token OpenID Connect temporar, generat în interiorul acelui workflow run securizat al tău. Identitatea este legată indisolubil de infrastructura GitHub Actions în momentul exact al build-ului. Acest mecanism acoperă o lacună critică în securitatea de software supply chain. Nu le mai ceri utilizatorilor să aibă încredere într-o locație de storage. În schimb, acel artifact devine self-authenticating. Aceste attestations îți schimbă modelul de securitate de la a avea încredere în locul unde se află un fișier, la a demonstra matematic locul în care a fost creat. Pentru că acesta este episodul final al seriei noastre GitHub Actions, te încurajez cu tărie să fii hands-on și să începi să construiești singur aceste workflow-uri. Vizitează devstories dot eu pentru a sugera subiecte pe care vrei să le vezi abordate în seriile noastre viitoare. Asta e tot pentru acest episod. Îți mulțumesc că ai ascultat și keep building!