Administrer og foretag fejlfinding af arbejdsprocesser i GitHub-handlinger

10 minutter

Husk, at dit mål er at automatisere kodeoprettelses- og publiceringsprocessen, så funktionerne opdateres, hver gang en udvikler føjer en ændring til kodebasen.

Hvis du vil implementere denne proces, får du mere at vide om, hvordan du:

Identificer den hændelse, der udløste en arbejdsproces.
Brug logfiler over arbejdsprocesser i GitHub-handlinger.
Gem og få adgang til buildartefakter.
Automatiser tilføjelse af en mærkat til en pullanmodning efter en gennemgang.

Identificer den hændelse, der udløste en arbejdsproces

Forståelse af, hvad der udløste en GitHub Actions-arbejdsproces, er afgørende for fejlfinding, overvågning og forbedring af CI/CD-pipelines. Typen af udløsere omfatter et push til en forgrening, en pullanmodning, der er oprettet eller opdateret, et planlagt job eller en manuel afsendelse. Du kan identificere den udløsende hændelse ved at undersøge kørslen af arbejdsprocessen, lagerændringerne og det relaterede GitHub-problem eller pullanmodningen.

Diagram, der viser forskellige arbejdsprocesudløsere i GitHub-handlinger, f.eks. push, pullanmodning, tidsplan og manuel afsendelse.

Hvad er en arbejdsprocesudløser?

En arbejdsprocesudløser er en hændelse, der medfører, at en arbejdsproces køres. GitHub understøtter forskellige typer udløsere, herunder:

push eller pull_request (baseret på kodeændringer)
workflow_dispatch (en manuel udløser)
schedule (cron job)
repository_dispatch (eksterne systemer)
Hændelser for problem-, diskussions- og pullanmodninger (f.eks. issues.opened, pull_request.closed)

Identificer udløserhændelsen

Du kan identificere en arbejdsprocesudløserhændelse på flere måder:

Brug brugergrænsefladen i GitHub-handlinger:
1. Vælg fanen Handlinger i dit lager.
2. Vælg en arbejdsproceskørsel.
En hændelsestype, f.eks push. , pull_requesteller workflow_dispatch, vises øverst i oversigten over kørsel af arbejdsprocessen.
Bruges github.event_name i loggene eller i en arbejdsproces.
- GitHub viser kontekstdata under kørsel af en arbejdsproces. Variablen github.event_name fortæller dig, hvilken hændelse der udløste arbejdsprocessen.
- Du kan udskrive oplysningerne i et trin til fejlfinding:
```
-name: Show event trigger
  run: echo "Triggered by ${{ github.event_name }}"
```
Brug oplysninger om kørsel af arbejdsproces:
- Hvis du undersøger arbejdsprocessen kører programmeringsmæssigt, f.eks. ved hjælp af API, indeholder kørselsobjektet en event egenskab, der angiver udløseren.
- Du kan finde bekræftelses-SHA (Secure Hash Algorithm), agent og tidsstempel for at spore, hvad der forårsagede udløseren.

Udled udløseren fra lagereffekter

Du har muligvis ikke direkte adgang til kørsel af arbejdsprocessen, men du vil stadig udlede, hvad der udløste kørslen af arbejdsprocessen baseret på lageraktivitet:

Observeret adfærd	Udløsende hændelse
Der blev sendt en ny bekræftelse til `main` , og arbejdsprocessen kørte.	`push` hændelse
En pullanmodning blev åbnet eller opdateret.	`pull_request` hændelse
En bidragyder kørte en arbejdsproces manuelt.	`workflow_dispatch`
Arbejdsprocessen kører dagligt på et bestemt tidspunkt.	`schedule` (cron)
Arbejdsprocessen kørte efter et opkald til en ekstern tjeneste.	`repository_dispatch`
Arbejdsprocessen kørte, da en etiket eller kommentar blev føjet til et problem.	`issues.*` hændelse

Ved at gennemse tidsstempler, pullanmodningsaktivitet og bekræftelseshistorik kan du ofte finde ud af, hvilken handling der fik arbejdsprocessen til at køre.

Sådan opsummerer du, hvordan du identificerer, hvad der udløste en arbejdsproces:

Kontrollér oversigten over arbejdsprocessens kørsel under fanen Handlinger .
Udskriv eller logfør github.event_name i arbejdsprocessen for at få synlighed.
Sammenlign tidsstempler og lageraktivitet (bekræftelser, pullanmodninger, problemer) for at udlede udløseren.
Brug den fulde event kontekst til at undersøge sagen nærmere.

Disse fremgangsmåder hjælper dig med at foretage fejlfinding, overvåge og forbedre pålideligheden af arbejdsprocesser på tværs af dine udviklings- og udrulningspipelines.

Forstå en arbejdsproceseffekt ved at læse konfigurationsfilen

Hvis du vil forstå, hvordan en arbejdsproces læser konfigurationsfilen, skal du analysere strukturen og indholdet af den fil, der .yml er gemt i .github/workflows/.

Konfigurationsfilen for arbejdsprocessen angiver følgende oplysninger om arbejdsprocessen:

Når den kører (i on sektionen ).
Hvad den gør (i jobs og steps).
Hvor den kører (sektionen runs-on ).
Hvorfor den kører (dens formål, f.eks. test, installation eller linting).
Hvordan den fungerer under bestemte betingelser (miljø, filtre, logik).

Fortolkning af en arbejdsproceseffekt

Identificer udløseren.

Hvis du vil identificere, hvilken handling der startede arbejdsprocessen, skal du on se afsnittet i arbejdsprocessen.

Her er et eksempel:
```
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:
```
Dette eksempel på arbejdsproces:
- Kører automatisk, når kode pushes til hovedgrenen (push).
- Kører, når en pullanmodning oprettes eller opdateres (pull_request).
- Kan udløses manuelt af en bruger (workflow_dispatch).
Identificer arbejdsprocesjob og -trin.

Se afsnittene og jobs i steps arbejdsprocessen for at finde ud af, hvad arbejdsprocessen gør.

Her er et eksempel:
```
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
```
Dette eksempel på arbejdsproces:
- Bruger et virtuelt Linux-miljø (runs-on).
- Tjekker lagerets kode (steps>name).
- Installerer projektafhængigheder (steps>name).
- Kører automatiserede test (steps>name).
Evaluer arbejdsprocessens formål og resultat.

Ved at læse konfigurationsfilen kan du beskrive det tilsigtede resultat af arbejdsprocessen:

"Denne arbejdsproces er en kontinuerlig integrationspipeline (CI). Det sikrer, at enhver ny kode, der pushes til lageret eller indsendes via pullanmodning, testes automatisk. Hvis test mislykkes, viser brugergrænsefladen i GitHub-arbejdsprocessen dette resultat for at hjælpe dig med at bevare kodekvaliteten."
Identificer eller angiv valgfrie funktioner, der påvirker den måde, arbejdsprocessen kører på:
- env angiver miljøvariabler.
- if tilføjer betinget logik for kun at køre bestemte trin, når kriterierne er opfyldt.
- timeout-minutes eller continue-on-error angive udførelse af arbejdsproces og fejlhåndtering.

Diagnosticer en mislykket arbejdsproceskørsel

Gå til fanen Handlinger i dit lager.
Find den mislykkede kørsel (typisk angivet med et rødt X).
Vælg den mislykkede arbejdsproces for at åbne kørselsoversigten.
Gennemse fejlen i logfilerne over arbejdsprocesser.
1. I kørselsoversigten skal du udvide hvert job og hvert trin, indtil du finder det, der angiver fejl.
2. Vælg jobbet eller trinnet for at få vist logfilerne.
3. Se efter:
  - Fejlmeddelelser
  - Stable spor
  - Udgangskoder
En mislykket test kan f.eks. vise npm ERR! Test failed eller exit code 1.
Kontrollér konfigurationsfilen for arbejdsprocessen.

Brug filen .yml til at bestemme:
- Hvad forsøgte hvert trin at gøre?
- Hvis der er miljøvariabler (env) eller betingelser (if), der påvirker udførelsen.
- Hvis fejlen skyldes en manglende afhængighed, syntaksfejl eller forkert konfigureret trin.
Hvis et trin mislykkes, skal du søge efter følgende årsager:
- Blev afhængigheder installeret i det foregående trin?
- Findes testfilerne, og overføres de lokalt?

Almindelige fejlscenarier

I følgende tabel beskrives almindelige scenarier med fejl i arbejdsprocesser:

Symptom	Sandsynlig årsag
Et trin mislykkes og returnerer `command not found`l	Manglende afhængighed eller forkert konfiguration
`npm install` Mislykkes.	Beskadiget `package-lock.json` fil eller et netværksproblem
Et testtrin mislykkes	Enhedstestproblemer, manglende konfigurationsfil eller ugyldig testsyntaks
`Permission denied` Vises.	Ugyldige filtilladelser eller manglende hemmeligheder

Identificer, hvordan du får adgang til arbejdsproceslogge i GitHub

Gå til fanen Handlinger i dit lager.
Vælg den relevante arbejdsproces på listen over arbejdsprocesser.

Hvis filen .yml f.eks. har følgende kode, vises der et link med titlen CI Workflow på listen:
```
name: CI Workflow
```
Vælg en bestemt kørsel.

På listen over kørsler, der viser status, skal du vælge tidsstempel eller bekræftelsesmeddelelse for den bestemte kørsel, du vil undersøge.
Udvid hvert job og hvert trin.

På siden med kørselsoversigten vises job, som de er defineret i arbejdsprocesfilen, f.eks. build eller test:
1. Vælg et job for at udvide det.
2. Udvid individuelle trin i jobbet, f.eks. "Installér afhængigheder" eller "Kør test".
Vis logoutput.

Hvis du vil have vist hele logoutputtet, herunder konsollogge, fejlmeddelelser og fejlfindingsoplysninger, skal du vælge et arbejdsprocestrin. Du kan kopiere, søge og downloade loggene.

I følgende tabel opsummeres de trin, du udfører for at få adgang til arbejdsproceslogge:

Action	Purpose
Fanen Handlinger	Få vist alle kørsler af arbejdsprocesser.
Vælg navnet på arbejdsprocessen	Filtrer kørsler efter arbejdsproces.
Vælg en kørsel	Se specifikke job- og trinresultater.
Udvid trin	Få vist detaljerede logge.
Download logfiler	Download logge til offline- eller teamfejlfinding.

Handlingslogge for buildet

Når en arbejdsproces kører, opretter den en log, der indeholder oplysninger om, hvad der er sket, og eventuelle fejl eller testfejl.

Hvis der opstår en fejl, eller hvis en test mislykkes, vises der et rødt X i stedet for et grønt flueben i loggene. Du kan undersøge detaljerne om fejlen eller fejlen for at undersøge, hvad der skete.

Skærmbillede af gitHub-handlingslog med oplysninger om en mislykket test.

Arbejd med artefakter

Når en arbejdsproces producerer noget andet end en logpost, kaldes produktet en artefakt. Det Node.js build producerer f.eks. en Docker-objektbeholder, der kan udrulles. Objektbeholderen er en artefakt, som du kan uploade til lageret ved hjælp af handlingen handlinger/upload-artefakt . Du kan senere downloade artefaktet fra lageret ved hjælp af actions/download-artifact.

Lagring af en artefakt bevarer den mellem job. Hvert job bruger en ny forekomst af en VM, så du kan ikke genbruge artefaktet ved at gemme det på den virtuelle maskine. Hvis du har brug for din artefakt i et andet job, kan du uploade artefaktet til lager i ét job og downloade det til det andet job.

Opbevaring af artefakter

Artefakter gemmes i lagerplads på GitHub. Pladsen er gratis for offentlige lagre, og noget lagerplads er gratis for private lagre, afhængigt af kontoen. GitHub gemmer dine artefakter i 90 dage.

Bemærk i følgende arbejdsprocesstykke, at der i handlingen actions/upload-artifact@main er en path attribut. Værdien af denne attribut er stien til lagring af artefaktet. I dette eksempel skal du angive public/ for at uploade alt til en mappe. Hvis du kun vil uploade en enkelt fil, skal du bruge noget som offentlig/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Hvis du vil downloade artefaktet til test, skal buildet fuldføres og uploade artefaktet. I følgende kode angiver du, at testjobbet afhænger af buildjobbet.

test:
    needs: build
    runs-on: ubuntu-latest

I følgende arbejdsprocesstykke downloader du artefaktet. Nu kan testjobbet bruge artefaktet til test.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

Du kan finde flere oplysninger om brug af artefakter i arbejdsprocesser under Lagring af arbejdsprocesdata som artefakter.

Automatiser anmeldelser i GitHub ved hjælp af arbejdsprocesser

Ud over at starte en arbejdsproces via GitHub-hændelser som push og pull-requestkan du køre en arbejdsproces efter en tidsplan eller efter en hændelse uden for GitHub.

Det kan være en god idé, at en arbejdsproces kun kører, når en bruger har fuldført en bestemt handling, f.eks. når en korrekturlæser har godkendt en pullanmodning. I dette scenarie kan du udløse på pull-request-review.

En anden handling, du kan udføre, er at føje en mærkat til pullanmodningen. I dette tilfælde skal du bruge handlingen pullreminders/etiket-når-godkendt-handling.

Her er et eksempel:

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

env I blokken skal du angive miljøvariabler for handlingen. Du kan f.eks. angive det antal godkendere, der kræves for at køre arbejdsprocessen. I dette eksempel er det et. Den secrets.GITHUB_TOKEN godkendelsesvariabel er påkrævet, fordi handlingen skal foretage ændringer i dit lager ved at tilføje en etiket. Til sidst skal du angive navnet på det navn, der skal tilføjes.

Tilføjelse af en etiket kan være en hændelse, der starter en anden arbejdsproces, f.eks. en fletning. Vi dækker denne hændelse i det næste modul, som beskriver brugen af kontinuerlig levering i GitHub-handlinger.

Feedback

Var denne side nyttig?