Använda utlösare för att styra när arbetsflödet körs

Slutförd

Nu har du ett fungerande arbetsflöde som distribuerar Bicep-filen till din Azure-miljö. Men när du ändrar filen måste du köra arbetsflödet manuellt. I den här lektionen får du lära dig hur du utlöser arbetsflödet så att det körs automatiskt när din Bicep-kod ändras.

Kommentar

Kommandona i den här enheten visas för att illustrera begrepp. Kör inte kommandona än. Du kommer att öva på det du lär dig här snart.

Vad är en arbetsflödesutlösare?

En arbetsflödesutlösare är ett villkor som, när det uppfylls, automatiskt kör arbetsflödet baserat på regler som du skapar. Du kan ange att utlösare ska köra arbetsflödet med schemalagda intervall. Du kan också ställa in utlösare för att köra arbetsflödet varje gång en fil på lagringsplatsen ändras. Du kan välja det andra alternativet eftersom det är en bra idé att köra alla dina tester och distributionssteg varje gång någon ändrar koden.

Om du inte använder en automatisk utlösare kan någon göra en ändring i en Bicep-fil och till och med checka in den och skicka den till lagringsplatsen, men om de glömmer att köra arbetsflödet blir det skillnad mellan resursdefinitionerna i Bicep-filen och de resurser som distribueras till din Azure-miljö. Anta att ytterligare ett par incheckningar och push-överföringar görs, men inte distribueras. Om någon introducerar ett fel eller en felkonfiguration i Bicep-filen i någon av dessa ändringar kan det vara svårt att spåra felet bland de flera incheckningar som senare distribueras samtidigt. Efter ett tag litar du inte på att din Bicep-kod verkligen representerar din infrastruktur, och dess värde urholkas.

När du konfigurerar arbetsflödet så att det körs varje gång du uppdaterar filerna börjar arbetsflödet köras så fort ändringarna skickas. Du får omedelbar feedback om ändringens giltighet och du kan vara säker på att produktionsmiljön alltid är uppdaterad.

Push-händelseutlösare

En vanlig typ av utlösare är en push-händelseutlösare, även kallad en kontinuerlig integrationsutlösare eller CI-utlösare. När du använder en push-händelseutlösare körs arbetsflödet varje gång du gör en ändring i en viss gren. Om du checkar in och push-överför en ändring till en annan gren utlöses inte arbetsflödet och körs inte. Det är vanligt att använda den här typen av utlösare mot din standard- eller huvudgren med den här koden:

on:
  push:
    branches:
      - main

Utlösare när flera grenar ändras

Du kan konfigurera utlösare för att köra arbetsflödet på en viss gren eller på uppsättningar med grenar. Anta till exempel att du skapar versionsgrenar som innehåller den kod som du distribuerar för en specifik version av projektet. Du kan använda grennamn som release/v1, release/v2 och så vidare. Du vill köra arbetsflödet när koden ändras på en gren som börjar med namnversionen /. Du kan använda ett ** jokertecken:

on:
  push:
    branches:
      - main
      - 'release/**'

Du kan också exkludera specifika grenar. Anta att du samarbetar med teammedlemmar i projektet. Dina kollegor skapar funktionsgrenar för att testa sina idéer i Bicep-filer. Alla funktionsgrenar har namn som funktion/tilläggsdatabas, funktion/förbättra prestanda och så vidare. Du vill köra arbetsflödet automatiskt på alla grenar förutom de funktionsgrenar som dina kollegor skapar. Genom att använda exclude egenskapen ser du till att arbetsflödet inte utlöses automatiskt för ändringar i funktionsgrenar:

on:
  push:
    branches-ignore:
      - 'feature/**'

Kommentar

Du kan exkludera vissa grenar med hjälp ! av tecknet. Anta att du vill utlösa arbetsflödet för huvudgrenen och alla versionsgrenar, förutom alfautgåvorna. Du kan använda ! tecknet för att uttrycka detta:

on:
  push:
    branches:
      - main
      - 'release/**'
      - '!release/**-alpha'

Du kan inte använda branches och branches-ignore tillsammans i en utlösare, så ! tecknet ger dig flexibilitet att styra utlösarens beteende.

Sökvägsfilter

Ibland har du filer på lagringsplatsen som inte är relaterade till distributionen. Du kan till exempel ha en distribuerad mapp på lagringsplatsen som innehåller din Bicep-kod och en dokumentundermapp som innehåller dina dokumentationsfiler. Du vill utlösa arbetsflödet när någon gör en ändring i någon av Bicep-filerna i distributionsmappen, men du vill inte utlösa arbetsflödet om någon bara ändrar en dokumentationsfil. Om du vill konfigurera en utlösare för att svara på ändringar i en specifik mapp på lagringsplatsen kan du använda ett sökvägsfilter:

on:
  push:
    paths:
      - 'deploy/**'
      - '!deploy/docs/**'

Om någon genomför en ändring som endast uppdaterar en dokumentationsfil körs inte arbetsflödet. Men om någon ändrar en Bicep-fil, eller även om de ändrar en Bicep-fil utöver en dokumentationsfil, kör utlösaren arbetsflödet.

Kommentar

Du kan också använda paths-ignore, som fungerar på ett liknande sätt som nyckelordet branches-ignore . Du kan dock inte använda paths och paths-ignore i samma utlösare.

Schemalägg arbetsflödet så att det körs automatiskt

Du kan köra arbetsflödet enligt ett angivet schema och inte som svar på en filändring. Du kan till exempel köra en nattlig version av din Bicep-kod eller automatiskt distribuera en testmiljö varje morgon. Använd nyckelordet schedule och ange frekvensen med hjälp av ett cron-uttryck:

on:
  schedule:
    - cron: '0 0 * * *'

Kommentar

Ett cron-uttryck är en specialformaterad sekvens med tecken som anger hur ofta något ska hända. I det här exemplet 0 0 * * * innebär det att köras varje dag vid midnatt UTC.

I en YAML-fil måste du lägga till citattecken runt strängar som innehåller * tecknet, till exempel cron-uttryck.

Schemahändelsen kör alltid arbetsflödet på standardgrenen för lagringsplatsen.

Använda flera utlösare

Du kan kombinera utlösare och scheman, som i det här exemplet:

on:
  push:
    branches:
      - main
  schedule:
    - cron: '0 0 * * *'

När du skapar en grenutlösare och en schemalagd utlösare i samma arbetsflöde körs arbetsflödet varje gång en fil ändras på den gren som anges i utlösaren och enligt det schema som du anger. I det här exemplet körs arbetsflödet varje dag vid midnatt UTC och även när en ändring skickas till huvudgrenen.

Dricks

Det är en bra idé att ange utlösare för varje arbetsflöde. Om du inte anger utlösare körs arbetsflödet som standard automatiskt när en fil ändras på en gren, vilket ofta inte är vad du vill.

Webhook-utlösare

GitHub tillhandahåller även webhook-händelser som körs automatiskt när vissa händelser inträffar på din lagringsplats. Dessa händelser inkluderar någon som skapar en gren, uppdaterar dina GitHub-problem eller ändringar i pull-begäranden. I allmänhet kräver dessa händelser inte att ditt Bicep-distributionsarbetsflöde körs, men du kan köra annan automatisering i stället.

Samtidighetskontroll

Som standard tillåter GitHub Actions att flera instanser av arbetsflödet körs samtidigt. Detta kan inträffa när du gör flera incheckningar till en gren inom en kort tid, eller om en tidigare körning inte har slutförts när ditt schema nästa utlösare.

I vissa situationer är det inte ett problem att ha flera samtidiga körningar av arbetsflödet. När du arbetar med distributionsarbetsflöden kan det dock vara svårt att se till att arbetsflödeskörningarna inte skriver över dina Azure-resurser eller din konfiguration på ett sätt som du inte förväntar dig.

För att undvika dessa problem kan du använda samtidighetskontroll. Använd nyckelordet concurrency och ange sedan en sträng som är konsekvent för alla körningar för arbetsflödet. Det är vanligtvis en hårdkodad sträng, som i det här exemplet:

concurrency: MyWorkflow

GitHub Actions ser sedan till att det väntar på att alla aktiva arbetsflödeskörningar ska slutföras innan en ny körning startas.