Brug udløsere til at styre, hvornår din arbejdsproces kører
Du har nu en arbejdsproces, der installerer din Bicep-fil i dit Azure-miljø. Når du ændrer filen, skal du dog køre arbejdsprocessen manuelt. I dette undermodul lærer du, hvordan du udløser din arbejdsproces til at køre automatisk, når din Bicep-kode ændres.
Seddel
Kommandoerne i dette undermodul vises for at illustrere begreber. Kør ikke kommandoerne endnu. Du skal snart øve dig i det, du lærer her.
Hvad er en arbejdsprocesudløser?
En arbejdsprocesudløser er en betingelse, der automatisk kører din arbejdsproces, når den er opfyldt, baseret på de regler, du opretter. Du kan angive udløsere til at køre arbejdsprocessen med planlagte intervaller. Du kan også angive udløsere til at køre din arbejdsproces, hver gang en fil i lageret ændres. Du kan vælge den anden indstilling, fordi det er en god idé at køre alle dine test og udrulningstrin, hver gang nogen ændrer din kode.
Hvis du ikke bruger en automatisk udløser, kan nogen foretage en ændring af en Bicep-fil og endda bekræfte den og sende den til lageret, men hvis de glemmer at køre arbejdsprocessen, vil der være en forskel mellem ressourcedefinitionerne i din Bicep-fil og de ressourcer, der er udrullet i dit Azure-miljø. Lad os antage, at der foretages et par flere bekræftelser og pushs, men ikke udrulles. Hvis nogen introducerer en fejl eller forkert konfiguration i Bicep-filen i en af disse ændringer, kan det være svært at spore fejlen blandt de flere bekræftelser, der installeres senere på én gang. Efter et stykke tid har du ikke tillid til, at din Bicep-kode virkelig repræsenterer din infrastruktur, og dens værdi er udhulet.
Når du konfigurerer arbejdsprocessen til at køre, hver gang du opdaterer dine filer, begynder din arbejdsproces at køre, når dine ændringer pushes. Du får øjeblikkelig feedback om din ændrings gyldighed, og du kan være sikker på, at dit produktionsmiljø altid er opdateret.
Pushhændelsesudløsere
En almindelig type udløser er en pushhændelsesudløser, der også kaldes en udløser til fortløbende integration eller CI-udløser. Når du bruger en pushhændelsesudløser, kører arbejdsprocessen, hver gang du foretager en ændring af en bestemt forgrening. Hvis du bekræfter og sender en ændring til en anden forgrening, udløses arbejdsprocessen ikke, og den kører ikke. Det er almindeligt at bruge denne type udløser i forhold til din standard- eller primære-forgrening med denne kode:
on:
push:
branches:
- main
Udløses, når flere forgreninger ændres
Du kan konfigurere udløsere til at køre din arbejdsproces på en bestemt forgrening eller på sæt af forgreninger. Lad os f.eks. antage, at du opretter udgivelsesgrene, der indeholder den kode, du udruller til en bestemt version af projektet. Du kan bruge forgreningsnavne som version/v1, version/v2osv. Du vil køre arbejdsprocessen, når koden ændres på en forgrening, der starter med navnet release/. Du kan bruge et ** jokertegn:
on:
push:
branches:
- main
- 'release/**'
Du kan også udelade bestemte forgreninger. Lad os antage, at du samarbejder med teammedlemmer på dit projekt. Dine kolleger opretter funktionsforgreninger for at afprøve deres ideer i Bicep-filer. Alle funktionsforgreninger har navne som funktions-/tilføjelsesprogramdatabase, funktion/forbedring af ydeevnenosv. Du vil køre arbejdsprocessen automatisk på alle forgreninger undtagen de funktionsgrene, som dine kollegaer opretter. Når du bruger egenskaben exclude, sikrer du, at arbejdsprocessen ikke udløses automatisk for ændringer af funktionsgrene:
on:
push:
branches-ignore:
- 'feature/**'
Seddel
Du kan udelade visse forgreninger ved hjælp af !-tegnet. Lad os antage, at du vil udløse din arbejdsproces for din hovedgren og alle udgivelsesgrene med undtagelse af alfaversionerne. Du kan bruge !-tegnet til at udtrykke dette:
on:
push:
branches:
- main
- 'release/**'
- '!release/**-alpha'
Du kan ikke bruge branches og branches-ignore sammen i én udløser, så det ! tegn giver dig fleksibilitet til at styre din udløsers funktionsmåde.
Stifiltre
Nogle gange har du filer i dit lager, der ikke er relateret til din installation. Du kan f.eks. have en installere mappe i dit lager, der indeholder din Bicep-kode, og en dokumentation undermappe, der indeholder dine dokumentationsfiler. Du vil udløse din arbejdsproces, når nogen foretager en ændring af nogen af Bicep-filerne i udrulle mappe, men du ikke vil udløse arbejdsprocessen, hvis nogen kun ændrer en dokumentationsfil. Hvis du vil konfigurere en udløser til at reagere på ændringer i en bestemt mappe i dit lager, kan du bruge et stifilter:
on:
push:
paths:
- 'deploy/**'
- '!deploy/docs/**'
Hvis nogen bekræfter en ændring, der kun opdaterer en dokumentationsfil, kører arbejdsprocessen ikke. Men hvis nogen ændrer en Bicep-fil, eller selvom vedkommende ændrer en Bicep-fil ud over en dokumentationsfil, kører udløseren arbejdsprocessen.
Seddel
Du kan også bruge paths-ignore, som fungerer på samme måde som nøgleordet branches-ignore. Du kan dog ikke bruge paths og paths-ignore i den samme udløser.
Planlæg, at arbejdsprocessen skal køre automatisk
Du kan køre arbejdsprocessen efter en angivet tidsplan og ikke som svar på en filændring. Du kan f.eks. køre en udgivelse af din Bicep-kode om natten eller automatisk installere et testmiljø hver morgen. Brug nøgleordet schedule, og angiv hyppigheden ved hjælp af et cron-udtryk:
on:
schedule:
- cron: '0 0 * * *'
Seddel
Et cron udtryk er en specielt formateret sekvens af tegn, der angiver, hvor ofte der skal ske noget. I dette eksempel betyder 0 0 * * *, at kører hver dag ved midnat UTC-.
I en YAML-fil skal du tilføje anførselstegn omkring strenge, der indeholder det * tegn, f.eks. cron-udtryk.
Planlægningshændelsen kører altid din arbejdsproces på standardgrenen for dit lager.
Brug flere udløsere
Du kan kombinere udløsere og tidsplaner, f.eks. i dette eksempel:
on:
push:
branches:
- main
schedule:
- cron: '0 0 * * *'
Når du opretter en forgreningsudløser og en planlagt udløser i den samme arbejdsproces, køres arbejdsprocessen, hver gang en fil ændres på den forgrening, der er angivet i udløseren og efter den tidsplan, du har angivet. I dette eksempel kører arbejdsprocessen hver dag ved midnat UTC, og når en ændring pushes til den primære forgrening.
Drikkepenge
Det er en god idé at angive udløsere for hver arbejdsproces. Hvis du ikke angiver udløsere som standard, kører din arbejdsproces automatisk, når en fil ændres på en forgrening, hvilket ofte ikke er det, du ønsker.
Webhookudløsere
GitHub leverer også webhookhændelser, der kører automatisk, når visse hændelser sker i dit lager. Disse hændelser omfatter en person, der opretter en forgrening, opdateringer til dine GitHub-problemer eller ændringer af pullanmodninger. Generelt kræver disse hændelser ikke, at din Bicep-udrulningsarbejdsproces kører, men du kan køre anden automatisering i stedet.
Samtidighedskontrol
GitHub-handlinger gør det som standard muligt at køre flere forekomster af arbejdsprocessen samtidigt. Dette kan ske, når du foretager flere bekræftelser på en forgrening inden for kort tid, eller hvis en tidligere kørsel ikke er afsluttet, når din tidsplan næste udløser.
I nogle situationer er det ikke et problem at have flere samtidige kørsler af arbejdsprocessen. Når du arbejder med udrulningsarbejdsprocesser, kan det dog være en udfordring at sikre, at dine arbejdsproceskørsler ikke overskriver dine Azure-ressourcer eller -konfigurationen på måder, du ikke forventer.
Du kan undgå disse problemer ved at anvende samtidighedskontrol. Brug nøgleordet concurrency, og angiv derefter en streng, der er ensartet på tværs af alle kørslerne for arbejdsprocessen. Det er normalt en hard-coded streng, f.eks. i dette eksempel:
concurrency: MyWorkflow
GitHub-handlinger sikrer derefter, at den venter på, at en aktiv arbejdsproces køres, før den starter en ny kørsel.