Afhankelijkheden cachen voor meer snelheid

Twee cruciale parameters voor actions/cache zijn key en path:

• key: Een unieke tekenreeks die je cache identificeert. Als er een cache met deze sleutel wordt gevonden, wordt die teruggezet.
• path: De bestandspaden of mappen die je wilt cachen. Hiermee geef je de actie aan *wat* die moet opslaan of terugzetten.

De sleutel bevat vaak een hashwaarde van afhankelijkheidsbestanden, zodat de cache ongeldig wordt gemaakt wanneer afhankelijkheden wijzigen.

Laten we node_modules cachen voor een Node.js-project. We gebruiken hashFiles om een dynamische sleutel te maken op basis van package-lock.json.

Probeer dit eenvoudige werkstroomfragment uit te voeren:

Wat als je exacte key niet overeenkomt met een cache? Dan zijn restore-keys handig!

restore-keys bevat een lijst met terugvalsleutels waarnaar gezocht wordt. Als de primaire sleutel, bijvoorbeeld npm-${{ hashFiles(...) }}, niet wordt gevonden, zoekt GitHub Actions in volgorde naar een cache met de sleutels uit restore-keys.

In ons voorbeeld zoekt npm- naar elke cache die met "npm-" begint. Dat is nuttig als alleen kleine wijzigingen in versies van afhankelijkheden zijn aangebracht.

Caching is niet alleen voor Node.js! Je kunt hetzelfde principe toepassen op andere talen, zoals Python. Hier cachen we de virtuele omgeving van Python en de cache van pip.

De sleutel gebruikt hier hashFiles('requirements.txt') en het pad verwijst naar de virtuele omgeving en de cachemap van pip.

Een cache is alleen nuttig als die actueel genoeg is. Als je afhankelijkheden wijzigen, moet je cache dat ook doen!

De cache wordt automatisch ongeldig gemaakt als je primaire key, bijvoorbeeld npm-${{ hashFiles('package-lock.json') }}, wijzigt. Als package-lock.json wordt bijgewerkt, verandert de hash en wordt er een nieuwe cache gemaakt.

Je kunt een cache ook geforceerd opnieuw opbouwen door de sleutel handmatig te wijzigen, bijvoorbeeld door een versietoevoeging zoals npm-v2-${{ hashFiles(...) }} toe te voegen.

Het is goed om te weten hoe caching op de achtergrond werkt:

• Bereik: Caches hebben een bereik per repository en per vertakking. Een cache op de main-vertakking wordt niet gebruikt op een functietak, tenzij je lookup-path expliciet configureert.
• Groottebeperking: Elke cache kan maximaal 10 GB groot zijn.
• Bewaartermijn: Caches worden 7 dagen na de laatste toegang bewaard. Oude, ongebruikte caches worden automatisch verwijderd.

Haal het meeste uit caching:

• Gebruik hashFiles: Koppel je cachesleutel altijd aan manifestbestanden van afhankelijkheden, zoals package-lock.json en requirements.txt.
• Wees specifiek met path: Cache alleen wat nodig is, zoals node_modules en ~/.cache/pip.
• Gebruik restore-keys: Geef terugvalopties op voor een hoger aantal cachetreffers.
• Cache geen vluchtige gegevens: Cache geen bestanden die vaak wijzigen of zeer groot en uniek zijn per uitvoering, zoals bouwartefacten die voor implementatie bedoeld zijn.

Goed gedaan! Je hebt geleerd hoe je caching in GitHub Actions implementeert om je CI/CD-werkstromen aanzienlijk te versnellen.

• De actie actions/cache is je hulpmiddel.
• Gebruik key en path om te bepalen wat je cacht en hoe je dat doet.
• hashFiles maakt dynamische sleutels voor slimme ongeldigmaking.
• restore-keys biedt waardevolle terugvalopties.

Door afhankelijkheden slim te cachen, bespaar je bouwtijd en rekenresources, waardoor je pijplijnen efficiënter worden!