GitHub kampt maandagavond 5 oktober met vertraging bij het starten van automatische softwaretaken. Voor studententeams en bedrijven in Nederland en België kan dat betekenen dat een controle of geplande publicatie op zich laat wachten. Wie een website of app wil bijwerken, moet daarom nagaan of de benodigde taak werkelijk is begonnen en afgerond.
De eerste officiële storingsmelding verscheen om 21.11 uur Nederlandse tijd. Om 22.39 uur meldde GitHub nog onderzoek naar vertragingen en mislukte taken bij het toewijzen van zijn eigen uitvoercomputers. Het bedrijf werkt aan beperking van de gevolgen, maar noemt geen hersteltijd of aantal getroffen gebruikers.
Een vertraagde controle is nog geen afgekeurde wijziging
Die uitvoercomputers, runners genoemd, voeren de opdrachten van GitHub Actions uit. Ze kunnen bijvoorbeeld een project ophalen en de tests draaien die moeten aantonen of een wijziging werkt. Gewoonlijk regelt GitHub de computer en het onderhoud daarvan. Tijdens deze storing zit de vertraging volgens het bedrijf bij het toewijzen van zo’n computer, dus vóór de betreffende taak kan starten. Een ontbrekend testresultaat bewijst dan nog niet dat de nieuwe software een fout bevat.
Wachten kent wel grenzen. GitHubs documentatie zegt dat een taak die al in de wachtrij staat wordt geschrapt wanneer een eigen GitHub-computer die niet binnen 45 minuten verwerkt. Een opdracht die door een onbeschikbare Actions-dienst niet binnen 30 minuten in de wachtrij komt, vervalt eveneens. Dat zijn algemene dienstregels, geen meting van hoeveel taken bij dit incident zijn verdwenen.
Controleer welke versie je opnieuw laat uitvoeren
Na herstel kan een bevoegde teamgenoot een bestaande uitvoering opnieuw starten. GitHub staat dat tot 30 dagen na de eerste uitvoering toe aan mensen met schrijfrechten voor het project. Je kunt de hele reeks opnieuw laten lopen, alleen de mislukte taken of een afzonderlijke taak. Daarmee krijgt een team een concrete herstelmogelijkheid als werk niet goed is doorgekomen.
Daarbij gebruikt GitHub dezelfde softwareversie als bij de oorspronkelijke uitvoering en de rechten van degene die die eerste uitvoering activeerde. Opnieuw starten controleert dus niet vanzelf de nieuwste wijziging die iemand intussen heeft toegevoegd. Voor een deadline telt daarom het resultaat bij de juiste versie. Een oude uitvoering die alsnog slaagt, geeft op zichzelf geen uitsluitsel over later toegevoegd werk.
Een eigen computer vraagt ook eigen beheer
Een alternatief is een uitvoercomputer die het team zelf beheert. Volgens GitHub kan dat een bestaande fysieke of virtuele machine zijn, op kantoor of in een cloud. Dat geeft meer controle over de hardware en programma’s. Het team betaalt en onderhoudt dan wel zijn machines en moet zelf het besturingssysteem en de overige software bijwerken. GitHub werkt alleen zijn runnerprogramma automatisch bij. Dat is een wezenlijk verschil met de onderhouden GitHub-computers. Voor teams met zo’n bestaande omgeving is dit een andere werkwijze; voor anderen is het geen directe oplossing die je met één druk op de knop inschakelt. Zo’n overstap vraagt dus een eigen beheerkeuze voor werk en studie.
Verder bij de bron
Lees zelf de onderzoeken, uitleg en aankondigingen achter dit verhaal.