GitHub udvider opbevaringsreglerne til checks, kørsler og statusser
GitHub meddelte den 1. oktober 2026, at checks, workflow-kørsler og statusser nu følger samme opbevaringsindstilling som Actions-logs og artifacts. Ændringen er relevant for teams, der bruger gammel kørselsdata til rapporter og fejlsøgning.
Flere poster følger samme periode
Poster ryddes automatisk op, når de overskrider den konfigurerede periode. Det gælder også checks og statusser fra tredjepartsapps. Repository-indstillinger er fortsat begrænset af organisationens og virksomhedens rammer.
For offentlige repositories er maksimum 90 dage. GitHub understreger, at en ændret indstilling ikke genskaber allerede fjernede data. Den udvidede regel gælder GitHub Actions på github.com.
Find de rapporter, som bruger gammel historik
Min anbefaling er at identificere de spørgsmål, teamet forventer at kunne besvare flere måneder senere. Det kan være, hvilken kontrol der blev kørt ved en bestemt levering, eller hvordan en kørselsserie udviklede sig.
Et tænkt dashboard kan hente alle tilgængelige kørsler hver uge. Hvis ældre poster forsvinder fra kilden, bør rapportens læser kunne se, at dækningen har ændret sig.
Skeln mellem manglende historik og manglende handling
En post, der ikke længere kan findes, er ikke alene bevis på, at arbejdet aldrig blev udført. Teamet bør undersøge opbevaringsreglen og tidligere dokumentation, før det drager den konklusion.
Beskriv i rapporteringen, hvilken periode udtrækket dækker. Hvis der er et hul i grundlaget, skal hullet fremgå, så et ufuldstændigt udtræk ikke kommer til at ligne en fuld historik.
Bevar nødvendigt bevis med et tydeligt formål
Afklar, hvilke resultater der skal kunne genfindes, og hvor teamet gemmer dem. Et kort leveringsbevis kan i nogle tilfælde være mere anvendeligt end en stor, ustruktureret samling logs.
Artiklen giver ikke en universel opbevaringsfrist eller en juridisk anbefaling. Den praktiske opgave er at få rapporternes forventninger og de faktiske systemindstillinger til at passe sammen.