GitHub Actions cache: a gyorsítás titkokat is kiszivárogtathat

A GitHub gyorsítótárazási szabályai szerint a megfelelő kulccsal mentett fájlok újabb CI-futásban visszaállíthatók, de a cache-t olvasni képes futások a benne felejtett titkokat is kinyerhetik. A GitHub Actions cache használatakor ezért a kulcsot a függőségeket rögzítő fájlhoz kell kötni, a mentett útvonalat pedig a szükséges csomagokra kell szűkíteni.

A pontos kulcstalálat időt takaríthat meg, de a visszaállítás és a sikeres feladat után végzett mentés is időbe kerül. Npmnél és pipnél a letöltött csomagokat érdemes először gyorsítótárazni; a telepítési parancs ezek után is lefut. Docker-buildnél külön rétegtár használható, amelynek méretét és visszaállítási idejét ugyanúgy ellenőrizni kell.

A kulcs a függőséggel együtt változzon

Egy npm-projektben használható kulcs például a ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }} kifejezés. Az operációs rendszer és a csomagkezelő elkülöníti az eltérő környezeteket; a zárolófájl hash-e új kulcsot ad, amikor a rögzített függőségek változnak. A mintát a projekt tényleges zárolófájljához igazítsd: egy nem létező vagy rossz helyen keresett fájl nem biztosítja a kívánt érvénytelenítést.

Az actions/cache lépésben a restore-keys értéke lehet ${{ runner.os }}-npm-. Ha az új zárolófájlhoz még nincs pontos találat, az akció ezzel az előtaggal korábbi csomagokat állíthat vissza, amelyekből a telepítő felhasználhatja a még megfelelőket. A cache-hit kimenet csak az elsődleges kulcs pontos egyezésekor igaz; a részleges találatot és a tényleges hiányt külön érdemes látni a futási adatokban.

Azonos kulcs alá csak egymással használható tartalom kerüljön. Eltérő operációs rendszernél vagy a telepített csomagokkal össze nem férő eszközverziónál külön kulcs indokolt; minden commit azonosítójának beépítése viszont jellemzően új bejegyzést készítene minden futáshoz. A túl tág visszaállítási előtagot is kerüld, mert olyan archívumot találhat meg, amelynek újbóli feldolgozása már nem segít.

Npm és Python: a letöltéseket mentsd

Egy Linuxon futó npm-feladat feltételezett actions/cache beállításában a path értéke ~/.npm, a key a zárolófájl hash-ét tartalmazza, a restore-keys pedig a fent megadott npm-előtag. A cache-lépés után továbbra is futtasd az npm ci parancsot, majd a teszteket. A ~/.npm letöltési tár visszaállítása nem jelenti azt, hogy a munkakönyvtárban már ott van a kész node_modules.

Egyszerűbb munkafolyamatban az actions/setup-node cache: npm beállítása elvégzi a csomagkezelő tárának mentését és visszaállítását. A cache-dependency-path: package-lock.json megadja, melyik fájl változását kell figyelni; más könyvtárban lévő vagy több zárolófájl esetén ehhez igazítsd az útvonalat. Egyedi actions/cache lépés akkor hasznos, ha saját útvonalra, visszaállítási előtagra vagy külön cache-hit kimenetre van szükség. Ugyanazt a letöltési tárat nem érdemes mindkét módszerrel menteni.

Python-projektnél az actions/setup-python cache: pip beállítása a pip letöltési tárát használja. Ha a feltételezett projekt requirements.lock fájlban rögzíti a verziókat, a cache-dependency-path: requirements.lock érték ehhez kötheti a kulcsot; utána a python -m pip install -r requirements.lock parancs továbbra is szükséges. Ha a követelményfájl szabad verziótartományokat enged, változatlan fájl mellett is megjelenhet új csomagverzió. A pontosan rögzített függőségek ezért a megismételhető telepítést és a cache találatának értelmezését is segítik.

Docker-buildnél a rétegeknek saját cache kell

A Docker-build rétegeit külön kezeld az npm vagy a pip letöltési tárától. A Docker gha háttértárának leírása a cache-from: type=gha és cache-to: type=gha beállítást mutatja a buildhez, és a háttértárat kísérletiként jelöli. A docker/build-push-action használatakor a szükséges cache-szolgáltatási adatokat az akció kezeli; közvetlen buildx parancsnál ezek átadására külön figyelni kell.

Ha ugyanaz a munkafolyamat több képet épít, mindegyikhez saját scope tartozzon. Egy feltételezett app képhez a cache-from: type=gha,scope=app és a cache-to: type=gha,scope=app értékek összetartoznak; másik kép más scope-ot kap. Enélkül az alapértelmezett buildkit scope alatt a képek cache-e felülírhatja egymást. A Dockerfile-ban a függőségfájlokat a gyakran változó forrás előtt másolva a forrás módosítása ritkábban érvényteleníti a függőségek telepítési rétegét.

A cache hozzáférési határ, nem titoktároló

A pull request futása visszaállíthatja a célág vagy az alapértelmezett ág elérhető cache-bejegyzéseit. Ha egy token, hitelesítő fájl vagy érzékeny napló a mentett path alá kerül, az archívummal együtt olvashatóvá válhat. A tartalom nincs aláírva vagy külön ellenőrizve; a visszaállított, később végrehajtott fájlok módosítása ezért a titokszivárgástól különálló, cache-mérgezési kockázat.

A mentett útvonalat a tényleges fájlok alapján szűkítsd, és a szükséges hitelesítő adatot a GitHub Actions secrets mechanizmusával add át a megfelelő lépésnek. Az alacsony bizalmi szintű, alapértelmezett ágon futó események cache-hozzáférése alaphelyzetben csak olvasást enged; egy kifejezetten írásra állított cache-mode ismét lehetővé teheti a mérgezett bejegyzés mentését. A szokásos pull_request futások bejegyzései a saját merge refjükhöz kötődnek, ezért ezeket nem szabad összekeverni az alapértelmezett ág cache-ének írásával.

A teljes feladat ideje dönt

A nagy archívum visszaállítása önmagában elviheti a letöltésen megtakarított időt. A RunsOn futtatói mérésében egy 4 GB-os fájl actions/cache segítségével történő visszaállítása 41 másodpercet vett igénybe a GitHub négy virtuális processzoros x64 futtatóján. A fájlt a tesztben mentés után törölték, majd azonnal visszaállították; ez a konkrét konfiguráció eredménye, nem egy npm-, Python- vagy Docker-feladat várható futásideje.

A saját munkafolyamathoz rögzítsd a cache nélküli telepítés vagy build idejét, a visszaállítás és a mentés idejét, a mentett archívum méretét, a cache-hit értékét és a teljes feladat idejét. Külön sorba kerüljenek a hideg, a pontos találatos és a részleges találatos futások. Az összevetéshez azonos futtatótípust és függőségkészletet használj, majd több futás alapján ítélj: egyetlen mérésben a hálózat vagy a csomagtár pillanatnyi állapota is jelentős eltérést okozhat.

Ha gyakori a pontos találat, de a teljes feladat alig gyorsul, a mentett útvonal méretét és a visszaállítás idejét vizsgáld meg. Ha minden futás új kulcsot kap, előbb a zárolófájl útvonalát és a kulcs túl változékony részeit ellenőrizd. A cache akkor éri meg, ha a teljes CI-feladat mért ideje csökken, és a mentett állományok között nincs olyan adat, amelyet egy másik futásnak nem szabadna olvasnia.

Olvassa el ezt is:

• Az MI gyorsítja a fejlesztést, mégis 42% kiégettebbnek érzi magát
• Cursor vagy GitHub Copilot: az ügynökhasználat írja át a havidíjat