Förstå GitHub Actions

Slutförd

Du kan automatisera stegen i distributionsprocessen med hjälp av ett arbetsflöde. Varje gång du gör en ändring i koden och genomför ändringen till git-lagringsplatsen kör arbetsflödet din fördefinierade process. Ett arbetsflöde kan kontrollera om din Bicep-kod uppfyller dina kvalitetsstandarder och sedan automatisera åtgärderna för att distribuera dina resurser till Azure. Processen definieras i en arbetsflödesdefinition som du skapar.

GitHub Actions är en funktion i GitHub. GitHub är också värd för de Git-lagringsplatser som du använder för att lagra och dela din kod med dina medarbetare. När du lagrar din Bicep-kod på GitHub kan GitHub Actions komma åt din kod för att automatisera distributionsprocesserna. I den här lektionen får du lära dig mer om GitHub Actions.

Vad är ett arbetsflöde?

Ett arbetsflöde är en konfigurerbar repeterbar process som definieras i en fil som används för att testa och distribuera koden. Ett arbetsflöde består av alla steg, i rätt ordning, som du behöver köra.

När du arbetar med GitHub Actions definierar du arbetsflödeskonfigurationen i en YAML-fil. Eftersom en YAML-arbetsflödesfil är en kodfil lagras filen med din Bicep-kod i Git-lagringsplatsen i en mapp med namnet .github/workflows. En YAML-fil är en strukturerad textfil som liknar en Bicep-strukturerad textfil. Du kan skapa och redigera en YAML-fil med valfri textredigerare. I den här modulen använder du Visual Studio Code som redigerare. GitHub-webbgränssnittet innehåller verktyg som du kan använda för att visa och redigera YAML-filen för arbetsflödet, samarbeta med arbetsflödesdefinitionen och för att hantera olika versioner av arbetsflödesfilen med hjälp av incheckningar och grenar.

Löpare

Hittills har du distribuerat dina Bicep-filer från den lokala datorn. När du har skrivit en Bicep-mall distribuerar du den till Azure med hjälp av Azure CLI eller Azure PowerShell. De här verktygen använder datorns resurser för att skicka mallen till Azure. De använder din personliga identitet för att autentisera dig till Azure och för att kontrollera att du har behörighet att distribuera resurserna.

Ett arbetsflöde behöver också åtkomst till en dator eller GPU med rätt operativsystem och maskinvaruplattform så att det kan köra distributionsåtgärderna. GitHub Actions använder löpare, som är datorer som är konfigurerade för att köra distributionssteg för ett arbetsflöde. Varje löpare har redan Bicep- och Azure-verktygen som du använde i tidigare moduler, så att de kan göra samma saker som du gör från din egen dator. I stället för ett mänskligt körningskommando instruerar GitHub Actions-tjänsten löparen att köra de steg som du har definierat i YAML-arbetsflödets fil.

GitHub Actions tillhandahåller flera typer av löpare för olika operativsystem, till exempel Linux eller Windows, och olika uppsättningar med verktyg. GitHub hanterar dessa löpare, så du behöver inte underhålla någon beräkningsinfrastruktur för löparna. Löparna kallas ibland GitHub-värdbaserade löpare eller värdbaserade löpare eftersom de finns för din räkning. När arbetsflödet körs skapas en värdbaserad löpare automatiskt. När arbetsflödet är klart tas den värdbaserade löparen bort automatiskt. Du kan inte komma åt värdbaserade löpare direkt, så det är viktigt att arbetsflödet innehåller alla steg som krävs för att distribuera din lösning.

Kommentar

Du kan skapa en anpassad löpare som kallas en lokalt installerad löpare. Du kan skapa en lokalt installerad löpare om du har specifik programvara som du behöver köra som en del av arbetsflödet eller om du behöver kontrollera exakt hur löparen är konfigurerad. Vi diskuterar inte lokalt installerade löpare i den här modulen, men vi tillhandahåller en länk till mer information i avsnittet Sammanfattning.

Utlösare

Du använder en utlösare för att instruera GitHub Actions när du ska köra arbetsflödet. Du kan välja mellan flera typer av utlösare. För tillfället använder du en manuell utlösare för att berätta för GitHub Actions när du ska börja köra arbetsflödet. Senare i den här modulen får du lära dig mer om andra typer av utlösare.

Steg

Ett steg representerar en enda åtgärd som arbetsflödet utför. Ett steg liknar ett enskilt kommando som du kör i Bash eller PowerShell. För de flesta distributioner kör du flera steg i en sekvens. Du definierar sekvensen och all information om varje steg i yaml-filen för arbetsflödet.

GitHub Actions erbjuder två typer av steg:

• Kör steg: Du kan använda ett körningssteg för att köra ett enda kommando eller en sekvens med kommandon i Bash, PowerShell eller Windows-kommandogränssnittet.
• Åtgärdssteg: Ett åtgärdssteg är ett bekvämt sätt att komma åt många olika funktioner utan att skriva skriptinstruktioner. Det finns till exempel en inbyggd uppgift för att distribuera Bicep-filer till Azure. Vem som helst kan skriva en åtgärd och dela den med andra användare. Det finns en stor uppsättning kommersiella uppgifter och uppgifter med öppen källkod.

Vissa föredrar att använda skriptinstruktioner i stället för åtgärder eftersom de ger mer kontroll över vad som körs. Andra föredrar att använda åtgärder så att de inte behöver skriva och hantera skript. I den här modulen använder vi en blandning av båda metoderna.

Projekt

I GitHub Actions representerar ett jobb en ordnad uppsättning steg. Du har alltid minst ett jobb i ett arbetsflöde och det är vanligt att ha fler än ett jobb när du skapar komplexa distributioner.

Kommentar

Du kan ange att varje jobb ska köras på en annan löpare. Att köra jobb på olika löpare är användbart när du skapar och distribuerar lösningar som behöver använda olika operativsystem i olika delar av jobbarbetsflödet.

Anta till exempel att du skapar en iOS-app och appens serverdelstjänst. Du kan ha ett jobb som körs på en macOS-löpare för att skapa iOS-appen och ett annat jobb som körs på en Ubuntu- eller Windows-löpare för att bygga serverdelen. Du kan till och med uppmana arbetsflödet att köra de två jobben samtidigt, vilket påskyndar arbetsflödets körning.

Exempel på grundläggande arbetsflöde

Nu när du känner till de grundläggande GitHub Actions-begreppen ska vi titta på en enkel arbetsflödesdefinition i YAML:

name: learn-github-actions

on: [workflow_dispatch]

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
      - name: 'Run a one-line command'
        run: echo "hello from GitHub Actions"
      - name: 'Run a multi-line command'
        run: |
          echo "We'll add more steps soon."
          echo "For example, we'll add our Bicep deployment step."

Nu ska vi titta närmare på varje del av filen:

• name är namnet på arbetsflödet. Namnet visas i GitHub-webbgränssnittet.
• on anger när arbetsflödet ska köras. I det här fallet on: [workflow_dispatch] meddelar du GitHub Actions att du vill utlösa arbetsflödet manuellt.
• jobs grupperar alla jobb i arbetsflödet.
• say-hello är namnet på ditt första och enda jobb i det här arbetsflödet.
• runs-on instruerar arbetsflödet som ska användas när jobbet körs. I det här exemplet körs arbetsflödet på ett Ubuntu-operativsystem, som kommer från en pool med GitHub-värdbaserade löpare.
• steps visar sekvensen med steg som ska köras i jobbet. Yaml-exemplet har två steg. Båda stegen kör ett enkelt skript för att upprepa text. Varje steg har ett name värde som kan läsas av människor. Du ser namnet i arbetsflödesloggarna. Om du vill skapa ett flerradsskriptsteg använder du pipe-tecknet (|) som du ser i exemplet. När steget har körts visas utdata i arbetsflödesloggen.

Viktigt!

I YAML-filer är indrag viktigt. Ta en titt på yaml-exemplet. Vissa rader i YAML är indragna med två eller fyra blanksteg. Om du inte drar in filen korrekt kan GitHub Actions inte tolka den. Visual Studio Code hjälper dig att hitta och åtgärda fel i YAML-filindraget.