dev · · 21:02 · 2 min de citit
Cache GitHub Actions Niciodată Nu Salvează la Potrivirea Cheii: 23 de Zile de CI Învechit
O problemă cu cache-ul GitHub Actions a fost identificată, unde o potrivire exactă a cheii împiedică salvarea datelor noi în cache, ducând la dependențe învechite și timpi de build CI prelungiți. Problema apare deoarece cache-ul este tratat ca imuabil la o potrivire exactă a cheii, determinând rulările ulterioare să descarce în mod repetat pachete depășite.
Un dezvoltator s-a confruntat cu o încetinire semnificativă a build-urilor sale CI GitHub Actions, pașii de instalare crescând de la sub un minut la aproape trei minute pe parcursul a trei săptămâni, în ciuda lipsei modificărilor în fișierul workflow. Cauza principală a fost descoperită a fi comportamentul acțiunii `actions/cache`: atunci când o cheie de cache se potrivește exact cu o intrare existentă, acțiunea restaurează cache-ul, dar apoi omite pasul de salvare. Acest lucru înseamnă că, dacă dependențele sunt actualizate, cache-ul restaurat rămâne depășit, iar noile pachete trebuie descărcate și instalate la fiecare rulare ulterioară, chiar dacă pasul de cache raportează o restaurare reușită.
Explicația tehnică dezvăluie că intrările de cache sunt imuabile. O potrivire exactă a cheii semnalează că cache-ul este deja corect, deci nu se efectuează nicio actualizare. Pentru a rezolva acest lucru, autorul recomandă utilizarea `hashFiles()` a fișierului de blocare (de exemplu, `requirements.txt`) în cadrul cheii de cache. Acest lucru asigură că orice modificare a dependențelor generează o cheie nouă, unică. Opțiunea `restore-keys` este, de asemenea, crucială pentru furnizarea de prefixe de rezervă, permițând restaurarea cache-urilor mai vechi, compatibile, atunci când cheia primară lipsește, declanșând astfel o operațiune de salvare pentru dependențele actualizate.
În plus, articolul subliniază că cache-urile GitHub Actions sunt limitate la nivel de branch, ceea ce înseamnă că o rulare poate accesa doar cache-uri din propriul branch sau din branch-ul implicit. Acest lucru poate duce la porniri la rece pe branch-uri noi și la caching ineficient pentru pull request-uri. Soluția implică asigurarea că workflow-ul rulează și la push-uri pe branch-ul implicit pentru a popula un cache partajat. În plus, job-urile eșuate nu salvează cache-uri, necesitând o separare în acțiuni distincte de restaurare și salvare dacă pașii de build sunt lungi și predispuși la eșecuri, asigurându-se că munca valoroasă de instalare nu este pierdută.
$ sursa --originală
dev.to
Rezumat realizat de Sudofeed pe baza articolului original. Drepturile asupra conținutului aparțin sursei originale.