Snelle checkouts met de volledige geschiedenis

actions/checkout haalt standaard één commit op (fetch-depth: 1). Dat is de snelste checkout, en voor de meeste jobs de juiste.

Sommige jobs hebben geschiedenis nodig: een pull request vergelijken met zijn basisbranch, de laatste releasetag vinden of een changelog genereren. Die zetten fetch-depth: 0, waarmee elke versie van elk bestand wordt gedownload die de repository ooit heeft gehad. De meeste van die jobs lezen alleen commits en bestandsnamen, nooit de oude bestandsinhoud.

Voeg één regel toe

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
    filter: blob:none

filter: blob:none maakt een gedeeltelijke clone: alle commits en mapoverzichten, en de bestandsinhoud alleen voor de commit die je uitcheckt. Leest een latere stap een oudere versie van een bestand, dan downloadt git die op dat moment.

Wat het oplevert

Gemeten op een repository van ongeveer 5.000 bestanden en 4.600 commits, op gehoste runners, oktober 2026:

De besparing groeit met de geschiedenis van de repository. Een jonge repository met weinig commits wint er weinig mee.

Wanneer je het gebruikt

Gebruik het wanneer de Git-commando’s van de job commits, branches, tags of namen van gewijzigde bestanden lezen, bijvoorbeeld:

• git diff --name-only origin/main...HEAD
• git log --oneline, git describe --tags
• git merge-base

Laat het weg wanneer de job oude bestandsinhoud over veel commits leest, bijvoorbeeld git log -p over een lange reeks, git blame op veel bestanden, of een tool die elke historische versie doorloopt. Elk ontbrekend bestand wordt dan op verzoek gedownload, wat trager kan zijn dan de volledige clone.

Een git diff die inhoud toont (niet alleen namen) tussen twee commits, downloadt alleen de gewijzigde bestanden, in één keer. Dat is meestal nog steeds sneller dan een volledige clone.

Waarom dit niet de standaard is

fremforge zet dit om twee redenen niet voor elke job aan:

• Het vertraagt de standaardcheckout. Met fetch-depth: 1 heeft een gedeeltelijke clone een tweede rondgang nodig voor de bestanden, dus is hij trager, niet sneller.
• De repository heeft eigen instellingen nodig om te werken. De invoer filter schrijft de instellingen voor de gedeeltelijke clone in de uitgecheckte repository, zodat elke latere stap kan ophalen wat hij nodig heeft. Een instelling die voor de runner als geheel geldt, reist niet mee met de repository, en een stap die met een andere homedirectory draait, bijvoorbeeld in een jobcontainer, zou bij het eerste ontbrekende bestand falen.

De keuze blijft dus bij jou, per workflow.