Forstå GitHub-handlinger

Fuldført

Du kan automatisere trinnene i installationsprocessen ved hjælp af en arbejdsproces. Hver gang du foretager en ændring af din kode og bekræfter ændringen i dit Git-lager, kører arbejdsprocessen din foruddefinerede proces. En arbejdsproces kan kontrollere, om din Bicep-kode opfylder dine kvalitetsstandarder, og derefter automatisere handlingerne for at udrulle dine ressourcer til Azure. Processen er defineret i en arbejdsprocesdefinition, du opretter.

GitHub Actions er en funktion i GitHub. GitHub hoster også de Git-lagre, du bruger til at gemme og dele din kode med dine samarbejdspartnere. Når du gemmer din Bicep-kode på GitHub, kan GitHub-handlinger få adgang til din kode for at automatisere dine udrulningsprocesser. I dette undermodul får du mere at vide om GitHub-handlinger.

Hvad er en arbejdsproces?

En arbejdsproces er en konfigurerbar gentagelig proces, der er defineret i en fil, der bruges til at teste og installere din kode. En arbejdsproces består af alle de trin i den korrekte rækkefølge, som du skal udføre.

Når du arbejder med GitHub-handlinger, definerer du konfigurationen af arbejdsprocessen i en YAML-fil. Da en YAML-arbejdsprocesfil er en kodefil, gemmes filen sammen med din Bicep-kode i Git-lageret i en mappe med navnet .github/workflows. En YAML-fil er en struktureret tekstfil, der ligner en Bicep-fil med struktureret tekst. Du kan oprette og redigere en YAML-fil med en hvilken som helst teksteditor. I dette modul skal du bruge Visual Studio Code som editor. GitHub-webgrænsefladen indeholder værktøjer, som du kan bruge til at få vist og redigere din YAML-arbejdsprocesfil, til at samarbejde om definitionen af din arbejdsproces og til at administrere forskellige versioner af din arbejdsprocesfil ved hjælp af bekræftelser og forgreninger.

Løbere

Indtil nu har du installeret dine Bicep-filer fra din lokale computer. Når du har skrevet en Bicep-skabelon, udruller du den på Azure ved hjælp af Kommandolinjegrænsefladen i Azure eller Azure PowerShell. Disse værktøjer bruger computerens ressourcer til at sende skabelonen til Azure. De bruger din personlige identitet til at godkende dig på Azure og til at bekræfte, at du har tilladelse til at udrulle ressourcerne.

En arbejdsproces skal også have adgang til en computer eller GPU med det korrekte operativsystem og den korrekte hardwareplatform, så den kan udføre udrulningshandlingerne. GitHub Actions bruger løbere, som er computere, der er konfigureret til at køre installationstrin for en arbejdsproces. Hver løber har allerede det Bicep- og Azure-værktøj, du brugte i tidligere moduler, så den kan gøre de samme ting, som du gør fra din egen computer. I stedet for en person, der udfører kommandoer, instruerer tjenesten GitHub Actions løberen om at køre de trin, du har defineret i YAML-filen for arbejdsprocessen.

GitHub Actions indeholder flere typer løbere til forskellige operativsystemer, f.eks. Linux eller Windows, og forskellige sæt værktøjer. GitHub administrerer disse løbere, så du ikke behøver at vedligeholde nogen beregningsinfrastruktur for løberne. Løberne kaldes nogle gange GitHub-hostede løbere eller hostede løbere, fordi de hostes på dine vegne. Når din arbejdsproces kører, oprettes der automatisk en hostet løber. Når din arbejdsproces er færdig med at køre, slettes den hostede løber automatisk. Du kan ikke få direkte adgang til hostede løbere, så det er vigtigt, at din arbejdsproces indeholder alle de trin, der er nødvendige for at udrulle din løsning.

Seddel

Du kan oprette en brugerdefineret løber, der kaldes en selvværtsløber. Du kan oprette en selv hostet løber, hvis du har specifik software, som du skal køre som en del af din arbejdsproces, eller hvis du har brug for at styre præcist, hvordan løberen er konfigureret. Vi diskuterer ikke selv hostede løbere i dette modul, men vi giver et link til flere oplysninger i afsnittet Oversigt.

Udløser

Du bruger en udløser til at instruere GitHub-handlinger , når til at køre arbejdsprocessen. Du kan vælge mellem flere typer udløsere. I øjeblikket skal du bruge en manuel udløser til at fortælle GitHub-handlinger, hvornår du skal begynde at køre din arbejdsproces. Senere i dette modul får du mere at vide om andre typer udløsere.

Trin

Et trin repræsenterer en enkelt handling, som arbejdsprocessen udfører. Et trin svarer til en individuel kommando, som du kører i Bash eller PowerShell. For de fleste udrulninger udfører du flere trin i en sekvens. Du definerer sekvensen og alle detaljer for hvert trin i YAML-filen for arbejdsprocessen.

GitHub Actions indeholder to typer trin:

• Kør trin: Du kan bruge et kørselstrin til at køre en enkelt kommando eller en sekvens af kommandoer i Bash, PowerShell eller Windows-kommando shell.
• handlingstrin: Et handlingstrin er en nem måde at få adgang til mange forskellige funktioner på uden at skrive scriptsætninger. Der er f.eks. en indbygget opgave i at udrulle Bicep-filer til Azure. Alle kan skrive en handling og dele den med andre brugere. Der findes et stort sæt kommercielle opgaver og opgaver med åben kildekode.

Nogle foretrækker at bruge scriptsætninger i stedet for handlinger, fordi de giver mere kontrol over, hvad der udføres. Andre foretrækker at bruge handlinger, så de ikke behøver at skrive og administrere scripts. I dette modul bruger vi en blanding af begge tilgange.

Job

I GitHub-handlinger repræsenterer et job et ordnet sæt trin. Du har altid mindst ét job i en arbejdsproces, og det er almindeligt at have mere end ét job, når du opretter komplekse udrulninger.

Seddel

Du kan indstille hvert job til at køre på en anden løber. Kørsel af job på forskellige løbere er nyttigt, når du bygger og udruller løsninger, der skal bruge forskellige operativsystemer i forskellige dele af jobarbejdsprocessen.

Lad os f.eks. antage, at du bygger en iOS-app og appens back end-tjeneste. Du har muligvis ét job, der kører på en macOS-løber, til at bygge iOS-appen og et andet job, der kører på en Ubuntu- eller Windows-løber for at bygge backend. Du kan endda bede arbejdsprocessen om at køre de to job samtidigt, hvilket fremskynder udførelsen af arbejdsprocessen.

Eksempel på grundlæggende arbejdsproces

Nu, hvor du kender de grundlæggende begreber i GitHub-handlinger, kan vi se på en simpel arbejdsprocesdefinition 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."

Lad os se nærmere på hver del af filen:

• name er navnet på arbejdsprocessen. Navnet vises på GitHub-webgrænsefladen.
• on fortæller arbejdsprocessen, hvornår den skal udføres. I dette tilfælde fortæller on: [workflow_dispatch] GitHub-handlinger, som du vil udløse arbejdsprocessen manuelt.
• jobs grupperer alle job i arbejdsprocessen.
• say-hello er navnet på dit første og eneste job i denne arbejdsproces.
• runs-on instruerer den arbejdsproces, som løberen skal bruge, når den kører jobbet. I dette eksempel kører arbejdsprocessen på et Ubuntu-operativsystem, som kommer fra en pulje af GitHub-hostede løbere.
• steps viser sekvensen af trin, der skal køres i jobbet. Eksemplet YAML indeholder to trin. Begge trin kører et simpelt script for at gentage noget tekst. Hvert trin har en name værdi, som kan læses af mennesker. Du kan se navnet i arbejdsprocesloggene. Hvis du vil oprette et scripttrin med flere linjer, skal du bruge pipetegnet (|) som vist i eksemplet. Når trinnet er udført, kan du se outputtet i arbejdsprocesloggen.

Vigtig

Indrykning er vigtig i YAML-filer. Se eksemplet YAML. Nogle linjer i YAML indrykkes med to eller fire mellemrum. Hvis du ikke indrykker filen korrekt, kan GitHub-handlinger ikke fortolke den. Visual Studio Code hjælper dig med at finde og rette fejl i din YAML-filindrykning.