GitHub Actions: styr samtidiga körningar med concurrency

1. Välj vad som måste köras en gång i taget

En AI-genererad workflow-fil kan se rimlig ut och ändå lägga två oberoende kontroller i samma kö. Börja därför med en mening om behovet: ”För samma workflow och gren vill jag begränsa samtidigheten, men en pågående körning ska få slutföras.” Den meningen blir ditt granskningskriterium. Om önskemålet i stället är att ersätta gamla CI-körningar med en nyare behöver kriteriet också ange att pågående arbete får avbrytas.

GitHub tillåter concurrency på workflow- eller jobbnivå. En grupp begränsar samtidigheten i samma repository. Standardkön har högst en running och en pending; en ny väntande körning ersätter den tidigare väntande. cancel-in-progress: true tillåter dessutom avbrytning av pågående arbete. Det framgår av GitHubs regler för concurrency. Huvudprovet nedan gäller hela workflow-körningar och behåller standardkön.

Skriv ned vilket arbete som omfattas innan du låter AI ändra YAML. För ett workflow med flera jobb behöver du exempelvis avgöra om hela körningen ska begränsas eller bara ett visst jobb. Flytta inte blocket mellan nivåerna under samma prov: då ändrar du både omfattningen och beteendet som ska jämföras. Den här övningen har ett enda väntjobb för att göra resultatet lättare att följa.

2. Bygg ett separat repo med ett manuellt väntjobb

Skapa ett tomt testrepo utan produktionshemligheter, deployment eller koppling till appens data. Lägg följande fil i .github/workflows/concurrency-probe.yml och checka in den på repots standardgren. Workflow-syntaxen anger att workflow_dispatch kräver att workflow-filen finns på standardgrenen. YAML-filerna hör hemma i .github/workflows enligt samma referens.

name: concurrency-probe
on:
  workflow_dispatch:
permissions: {}
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: false
jobs:
  wait:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Wait for observation
        run: sleep 180

Jobbet väntar i tre minuter efter att steget börjat. Det är övningens valda observationsfönster, ingen uppmätt väntetid för GitHubs kö. Timeouten på tio minuter är en separat gräns för jobbet. Varken checkout, paketinstallation eller externa actions behövs för detta exempel. permissions: {} begär inga rättigheter för GITHUB_TOKEN; syntaxreferensen för permissions beskriver den tomma behörighetsmappningen.

Kontrollera manuellt att indragen matchar exemplet: concurrency ligger bredvid jobs, medan runs-on, timeout-minutes och steps ligger inne i jobbet wait. Den lokala dokumentationskontrollen omfattar dessa fält, triggern och grupputtrycket. Den visar inte att GitHub har accepterat din egen fil. Om Actions visar ett valideringsfel, spara meddelandet och rätta det innan du börjar protokollet.

3. Ge workflow och gren rätt grupp

Gruppen i exemplet kombinerar workflow-namnet med refen. GitHubs exempel för separata workflows använder samma uttryck. Gruppnamn är skiftlägesokänsliga; stora bokstäver skapar därför ingen separat grupp. Granska även de andra workflow-filerna i ditt testrepo innan du drar slutsatser om isoleringen.

För ett konkret tankeprov kan du kalla standardgrenen main. Då blir gruppen för exemplet concurrency-probe-refs/heads/main. På en gren som heter experiment blir den concurrency-probe-refs/heads/experiment. Skriv de två värdena på papper och jämför dem. Om din AI-genererade fil bara har gruppen ci hamnar båda i samma grupp. Om den bara använder refen kan två workflows på samma gren få samma grupp.

Prova isoleringen efter det första köprovet: skapa grenen experiment från den commit som innehåller workflow-filen och starta samma workflow där. Skapa därefter en kopia av filen med ett annat, tydligt namn, exempelvis concurrency-probe-second. Behåll övriga fält. Facit för gruppberäkningen är tre olika strängar för originalet på main, originalet på experiment och kopian på main. Två filer med samma name ger däremot inte den åtskillnad som du avsåg.

Skilj beräknad grupp från observerad körstatus i dina anteckningar. Att en körning inte har startat kan behöva undersökas separat; en olik gruppsträng är inget löfte om en viss starttid. Spara filnamn, workflow-namn och vald gren så att du kan förstå provet även efter att filerna ändrats.

4. Prova tre körningar och anteckna facit

Öppna testrepots Actions-vy och starta workflowet på samma gren tre gånger. Kalla dem A, B och C i ditt protokoll och spara länken till varje körning. Vänta tills A:s väntsteg faktiskt arbetar innan du startar B. Kontrollera sedan att B väntar på concurrency-gruppen innan du startar C. Gör alltså inga tre snabba klick utan observation mellan dem; då kan förutsättningarna för jämförelsen saknas.

Det dokumentationsbaserade facit nedan förutsätter att A fortfarande pågår när B och C köas i samma grupp. Om A hinner bli klar, gör om försöket med samma fil och ett nytt protokoll. Skriv faktiska statusar och klockslag i en separat kolumn. Lämna den tom om du bara läser guiden.

Standardkön sparar därmed inte alla dina beställningar. Det är en avgörande skillnad om AI beskriver konfigurationen som en vanlig kö där varje inkommen körning så småningom utförs. Bedöm förslaget mot ditt behov: räcker senaste väntande kontrollen, eller behöver du bevara flera beställningar? Detta prov visar bara standardfallet.

Låt provets körningar avslutas innan du gör nästa jämförelse. Ändra därefter enbart cancel-in-progress från false till true, checka in ändringen och upprepa starten av A och B på samma gren. Behåll workflow-namn, grupp, jobb och väntsteg. Avbrytningsregeln innebär då att en pågående A kan avbrytas när B kommer. Spara vad du faktiskt ser; kalla inte det tidigare tabellfacit för ett uppmätt resultat.

5. Skilj CI-avbrytning från deploykrav

En bra slutfråga till AI är: ”Förklara vilka körningar som delar grupp, vilka som kan ersättas medan de väntar och om pågående arbete får avbrytas. Använd min workflow-fil och ge ett facit för A, B och C med samma gren.” Acceptera svaret först när det beskriver precis de inställningar du har valt. Ett generellt påstående om att concurrency ”förhindrar konflikter” räcker inte som kontroll.

Den aktuella dokumentationen har även queue: max: upp till 100 körningar kan vänta, och tillkommande körningar avbryts om kön är full. Kombinationen med cancel-in-progress: true ger valideringsfel. GitHub beskriver FIFO efter när väntan på gruppen började, men garanterar inte dispatchordningen. Läs köinställningens begränsningar innan du väljer den; huvudexemplet använder inte max.

För deployment behöver du ett separat beslut om avbrutet arbete, återställning och data. Dra ingen slutsats om atomära ändringar från det här väntjobbet. Guiden kontrollerar gruppval och köbeteende, inte en deploymentprocess. Använd stoppregler för CI före merge när du vill avgöra vilka kontroller som måste godkännas. Läs även versionsgrinden för Actions-runnern om provmiljön behöver granskas.

Spara avslutningsvis workflow-filen, den avsedda gruppregeln, inställningen för avbrytning och protokollet med körningslänkar. Markera separat vad du bara härlett ur dokumentationen och vad du själv observerat. Ett godkänt läsarprov kräver rätt gruppvärden och observerade statusar under rätt förutsättningar. Om någon observation avviker, skriv avvikelsen och utred den innan du flyttar inställningen till ditt apprepo.