Delen via

Pijplijncache

Azure DevOps Services

Pijplijncaching kan helpen bij het verminderen van de buildtijd door gedownloade afhankelijkheden uit eerdere uitvoeringen opnieuw te gebruiken, zodat dezelfde bestanden niet opnieuw hoeven te worden gemaakt of opnieuw moeten worden gedownload. Dit is met name handig in scenario's waarbij dezelfde afhankelijkheden herhaaldelijk worden gedownload aan het begin van elke uitvoering. Dit is vaak een tijdrovend proces waarbij honderden of duizenden netwerkoproepen worden gebruikt.

Caching is het meest effectief wanneer de tijd die nodig is om de cache te herstellen en op te slaan minder is dan de tijd die nodig is om de bestanden opnieuw te genereren. In sommige gevallen biedt caching echter mogelijk geen prestatievoordelen en kan dit zelfs een negatieve invloed hebben op de buildtijd. Het is belangrijk om uw specifieke scenario te evalueren om te bepalen of caching de juiste aanpak is.

Notitie

Pijplijncache wordt niet ondersteund voor klassieke release-pijplijnen.

Wanneer gebruikt u pijplijnartefacten versus pijplijncaching

Pijplijncaching en pijplijnartefacten voeren vergelijkbare functies uit, maar zijn bedoeld voor verschillende scenario's en moeten niet door elkaar worden gebruikt.

  • Gebruik pijplijnartefacten: wanneer u specifieke bestanden moet nemen die door de ene taak zijn geproduceerd en deze met andere taken wilt delen (en deze andere taken mislukken waarschijnlijk zonder deze).

  • Pijplijncaching gebruiken: wanneer u de buildtijd wilt verbeteren door opnieuw bestanden te gebruiken van eerdere runs (en de afwezigheid van deze bestanden geen invloed heeft op het vermogen van de taak om te draaien).

Notitie

Pijplijncaching en pijplijnartefacten zijn gratis beschikbaar voor alle lagen (gratis en betaald). Zie Het opslagverbruik van artefacten voor meer informatie.

Vereisten voor zelf-hostende agents

De volgende uitvoerbare bestanden moeten zich bevinden in een map die wordt vermeld in de PATH omgevingsvariabele. Houd er rekening mee dat deze vereisten alleen van toepassing zijn op zelf-hostende agents, omdat gehoste agents vooraf zijn geïnstalleerd met de benodigde software.

Software/platform archiveren Ramen Linux Mac
GNU Teer Vereist Vereist Nee
BSD teer Nee Nee Vereist
7-ritssluiting Aanbevolen Nee Nee

Cachetaak: hoe het werkt

Caching wordt toegevoegd aan een pijplijn door de cachetaak toe te voegen aan de steps sectie van een taak.

Wanneer tijdens de uitvoering van de pijplijn een cachestap wordt aangetroffen, probeert de taak de cache te herstellen op basis van de opgegeven invoer. Als er geen cache wordt gevonden, wordt de stap voltooid en wordt de volgende stap in de taak uitgevoerd.

Zodra alle stappen in de taak zijn uitgevoerd, wordt automatisch een speciale stap 'Post-job: Cache' toegevoegd en geactiveerd voor elke stap 'herstelcache' die niet is overgeslagen. Deze stap is verantwoordelijk voor het opslaan van de cache.

Notitie

Caches zijn onveranderbaar. Zodra een cache is gemaakt, kan de inhoud ervan niet worden gewijzigd.

De cachetaak configureren

De cachetaak heeft twee vereiste argumenten: pad en sleutel:

  1. pad: het pad naar de map die u wilt opslaan. Dit kan een absoluut of relatief pad zijn. Relatieve paden worden geëvalueerd ten opzichte van $(System.DefaultWorkingDirectory).

    Aanbeveling

    U kunt vooraf gedefinieerde variabelen gebruiken om het pad op te slaan naar de map die u in de cache wilt opslaan. Jokertekens worden echter niet ondersteund.

  2. sleutel: Hiermee definieert u de id voor de cache die u wilt herstellen of opslaan. De sleutel bestaat uit een combinatie van tekenreekswaarden, bestandspaden of bestandspatronen, waarbij elk segment wordt gescheiden door een | teken.

    • Tekenreeksen:
      Een vaste waarde (zoals de cachenaam of de naam van een hulpprogramma) of afkomstig uit een omgevingsvariabele (zoals het huidige besturingssysteem of de naam van de taak).

    • Bestandspaden:
      Het pad naar een specifiek bestand waarvan de inhoud wordt gehasht. Het bestand moet bestaan op het moment dat de taak wordt uitgevoerd. Elk segment dat lijkt op een bestandspad wordt als zodanig behandeld, dus wees voorzichtig, vooral bij het gebruik van segmenten die . bevatten, omdat dit kan leiden tot fouten zoals "bestand bestaat niet".

      Aanbeveling

      Als u wilt voorkomen dat een padachtig tekenreekssegment wordt behandeld als een bestandspad, verpakt u het met dubbele aanhalingstekens, bijvoorbeeld: "my.key" | $(Agent.OS) | key.file

    • Bestandspatronen:
      Een door komma's gescheiden lijst met jokertekenpatronen in glob-stijl die moeten overeenkomen met ten minste één bestand. Voorbeelden:

      • **/yarn.lock: alle yarn.lock-bestanden onder de map bronnen.
      • */asset.json, !bin/**: alle asset.json bestanden die zich in een map onder de map bronnen bevinden, met uitzondering van bestanden in de bin-map .

De inhoud van een bestand dat wordt geïdentificeerd door een bestandspad of bestandspatroon, wordt gehasht om een dynamische cachesleutel te genereren. Dit is handig wanneer uw project bestanden bevat die uniek bepalen wat er in de cache wordt opgeslagen. Bijvoorbeeld bestanden zoalspackage-lock.json, yarn.lockof Gemfile.lockPipfile.lock worden vaak verwezen in een cachesleutel, omdat ze een unieke set afhankelijkheden vertegenwoordigen. Relatieve bestandspaden of -patronen worden opgelost op basis van $(System.DefaultWorkingDirectory).

  • Voorbeeld:

In het volgende voorbeeld ziet u hoe u Yarn-pakketten cachet:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/s/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       "yarn" | "$(Agent.OS)"
       "yarn"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

In dit voorbeeld bestaat de cachesleutel uit drie delen: een statische tekenreeks (yarn), het besturingssysteem waarop de taak wordt uitgevoerd (omdat de cache uniek is per besturingssysteem) en de hash van het yarn.lock bestand (waarmee de afhankelijkheden uniek worden geïdentificeerd).

Bij de eerste uitvoering nadat de taak is toegevoegd, rapporteert de cache-stap een 'cachemisser' omdat de cache die met deze sleutel is geïdentificeerd, niet bestaat. Na de laatste stap wordt een cache gemaakt op basis van de bestanden in $(Pipeline.Workspace)/s/.yarn en geüpload. Tijdens de volgende uitvoering rapporteert de cachestap een 'cachetreffer' en wordt de inhoud van de cache gedownload en hersteld.

Wanneer u de opslagplaats gebruikt checkout: self, wordt deze uitgecheckt naar $(Pipeline.Workspace)/sen bevindt uw .yarn map zich waarschijnlijk in de opslagplaats zelf.

Notitie

Pipeline.Workspace is het lokale pad op de agent waarop uw pijplijn wordt uitgevoerd, waar alle directories worden gemaakt. Deze variabele heeft dezelfde waarde als Agent.BuildDirectory. Als u de variabele niet gebruikt checkout: self, moet u ervoor zorgen dat u de YARN_CACHE_FOLDER variabele bijwerkt zodat deze verwijst naar de locatie van .yarn uw opslagplaats.

Herstelsleutels gebruiken

restoreKeys hiermee kunt u query's uitvoeren op meerdere exacte sleutels of sleutelvoorvoegsels. Het wordt gebruikt als een terugval wanneer de opgegeven key geen hit oplevert. Een herstelsleutel zoekt een sleutel op basis van een voorvoegsel en geeft het meest recent gemaakte cache-item terug. Dit is handig wanneer het systeem geen exacte overeenkomst kan vinden, maar toch een gedeeltelijke cache-hit wil gebruiken.

Als u meerdere herstelsleutels wilt opgeven, zet deze op afzonderlijke regels. De volgorde waarin de herstelsleutels worden geprobeerd, is van boven naar beneden.

  • Voorbeeld:

Hier volgt een voorbeeld van het gebruik van herstelsleutels voor het cachegeheugen van Yarn-pakketten:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

In dit voorbeeld probeert de cachetaak eerst de opgegeven sleutel te herstellen. Als de sleutel niet in de cache bestaat, wordt de eerste herstelsleutel geprobeerd: yarn | $(Agent.OS) Hiermee wordt gezocht naar cachesleutels die exact overeenkomen of beginnen met dit voorvoegsel.

Er kan een overeenkomst tussen voorvoegsels optreden als de hash van het yarn.lock bestand is gewijzigd. Als de cache bijvoorbeeld de sleutel yarn | $(Agent.OS) | old-yarn.lock bevat (waarbij old-yarn.lock een andere hash is dan de huidige yarn.lock), resulteert deze herstelsleutel in een gedeeltelijke cachetreffer.

Als de eerste herstelsleutel geen overeenkomst oplevert, wordt met de volgende herstelsleutel (yarn) gezocht naar een cachesleutel die begint met yarn. Voor overeenkomsten met voorvoegsels retourneert het herstelproces de laatst gemaakte cachevermelding.

Notitie

Een pijplijn kan meerdere cachetaken bevatten en er is geen opslaglimiet voor caching. Taken en werkzaamheden in dezelfde pijplijn hebben toegang tot en kunnen dezelfde cache delen.

Herstelvoorwaarde gebruiken

In sommige scenario's kunt u stappen voorwaardelijk uitvoeren op basis van of de cache is hersteld. U kunt bijvoorbeeld een stap overslaan waarmee afhankelijkheden worden geïnstalleerd als de cache is hersteld. Dit kan worden bereikt met behulp van het cacheHitVar argument.

Als u deze invoer instelt op de naam van een omgevingsvariabele, wordt de variabele ingesteld true op wanneer er sprake is van een cachetreffer, inexact als een herstelsleutel een gedeeltelijke cachetreffer oplevert en false als er geen cache wordt gevonden. U kunt vervolgens verwijzen naar deze variabele in een stapvoorwaarde of in een script.

Hier volgt een voorbeeld waarin de install-deps.sh stap wordt overgeslagen wanneer de cache wordt hersteld:

steps:
- task: Cache@2
  inputs:
    key: mykey | mylockfile
    restoreKeys: mykey
    path: $(Pipeline.Workspace)/mycache
    cacheHitVar: CACHE_RESTORED

- script: install-deps.sh
  condition: ne(variables.CACHE_RESTORED, 'true')

- script: build.sh

Isolatie en beveiliging van cache

Om isolatie tussen caches van verschillende pijplijnen en verschillende vertakkingen te garanderen, wordt elke cache opgeslagen in een logische container die een bereik wordt genoemd. Scopes fungeren als een beveiligingsgrens die het volgende garanderen:

  • Taken van één pijplijn hebben geen toegang tot caches vanuit een andere pijplijn.

  • Taken die pull-aanvragen bouwen, kunnen caches lezen uit de doelbranch (voor dezelfde pijplijn), maar kunnen geen caches schrijven (maken) in het bereik van de doelbranch.

Wanneer er tijdens een uitvoering een cachestap wordt aangetroffen, wordt de cache die door de sleutel wordt geïdentificeerd, aangevraagd bij de server. De server zoekt vervolgens naar een cache met deze sleutel in de scopes die zichtbaar zijn voor de taak en retourneert de cache (indien beschikbaar). Bij het opslaan van de cache (aan het einde van de taak) wordt een cache naar het bereik geschreven dat de pijplijn en tak vertegenwoordigt.

CI, handmatige en geplande runs

Draagwijdte Lezen Schrijven
Brontak Ja Ja
main filiaal Ja Nee
master filiaal Ja Nee

Pull-aanvragen uitvoeren

Draagwijdte Lezen Schrijven
Brontak Ja Nee
De doelvertakking Ja Nee
Tussenliggende vertakking (zoals refs/pull/1/merge) Ja Ja
main filiaal Ja Nee
master filiaal Ja Nee

Uitvoeren van pull-aanvraag-forks

Afdeling/Filiaal Lezen Schrijven
De doelvertakking Ja Nee
Tussenliggende vertakking (zoals refs/pull/1/merge) Ja Ja
main filiaal Ja Nee
master filiaal Ja Nee

Aanbeveling

Omdat caches al zijn afgestemd op een project, pijplijn en vertakking, hoeft u geen project-, pijplijn- of vertakkings-id's op te nemen in de cachesleutel.

Voorbeelden

Voor Ruby-projecten die Bundler gebruiken, overschrijft u de BUNDLE_PATH omgevingsvariabele om het pad in te stellen waar Bundler zoekt naar Gems.

Voorbeeld:

variables:
  BUNDLE_PATH: $(Pipeline.Workspace)/.bundle

steps:
- task: Cache@2
  displayName: Bundler caching
  inputs:
    key: 'gems | "$(Agent.OS)" | Gemfile.lock'
    path: $(BUNDLE_PATH)
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems

Bekende problemen en feedback

Als u problemen ondervindt bij het instellen van caching in uw pijplijn, controleert u de lijst met openstaande problemen in de microsoft/azure-pipelines-tasks opslagplaats. Als het probleem niet wordt vermeld, maakt u een nieuw probleem en geeft u de benodigde informatie over uw scenario op.

Vragen en Antwoorden

Kan ik een cache wissen?

A: Het wissen van een cache wordt niet ondersteund. U kunt echter treffers in bestaande caches voorkomen door een letterlijke tekenreeks (zoals version2) toe te voegen aan uw cachesleutel. Wijzig bijvoorbeeld de volgende cachesleutel zoals deze:

key: 'yarn | "$(Agent.OS)" | yarn.lock'

Naar dit:

key: 'version2 | yarn | "$(Agent.OS)" | yarn.lock'

V: Wanneer verloopt een cache?

A: Caches verlopen na zeven dagen zonder activiteit.

V: Wanneer wordt de cache geüpload?

A: Er wordt een cache gemaakt op basis van uw opgegeven path en geüpload na de laatste stap van de taak. Zie het voorbeeld voor meer informatie.

V: Is er een limiet voor de grootte van een cache?

A: Er is geen afgedwongen limiet voor de grootte van afzonderlijke caches of de totale cachegrootte binnen een organisatie.

Verwante inhoud

  • Last updated on