Behandle og feilsøke arbeidsflyter i GitHub-handlinger

  • 10 minutter

Husk at målet ditt er å automatisere kodebygg- og publiseringsprosessen slik at funksjonene oppdateres hver gang en utvikler legger til en endring i kodebasen.

Hvis du vil implementere denne prosessen, lærer du hvordan du:

  • Identifiser hendelsen som utløste en arbeidsflyt.
  • Bruk arbeidsflytlogger for GitHub-handlinger.
  • Lagre og få tilgang til byggartefakter.
  • Automatiser å legge til en etikett i en pull-forespørsel etter en gjennomgang.

Identifisere hendelsen som utløste en arbeidsflyt

Å forstå hva som utløste en Arbeidsflyt for GitHub-handlinger er avgjørende for feilsøking, overvåking og forbedring av CI/CD-datasamlebånd. Type utløsere inkluderer en push til en gren, en pull-forespørsel opprettet eller oppdatert, en planlagt jobb eller en manuell utsendelse. Du kan identifisere utløserhendelsen ved å undersøke arbeidsflytkjøringen, repositoriet endres og det relaterte GitHub-problemet eller pull-forespørselen.

Diagram som viser ulike arbeidsflytutløsere i GitHub-handlinger, for eksempel push, pull-forespørsel, tidsplan og manuell utsendelse.

Hva er en arbeidsflytutløser?

En arbeidsflytutløser er en hendelse som fører til at en arbeidsflyt kjøres. GitHub støtter ulike typer utløsere, inkludert:

  • push eller pull_request (basert på kodeendringer)
  • workflow_dispatch (en manuell utløser)
  • schedule (cron-jobber)
  • repository_dispatch (eksterne systemer)
  • Problem-, diskusjons- og pull-forespørselshendelser (for eksempel , issues.openedpull_request.closed)

Identifiser utløserhendelsen

Du kan identifisere en arbeidsflytutløserhendelse på flere måter:

  • Bruk brukergrensesnittet for GitHub-handlinger:

    1. Velg Handlinger-fanen i repositoriet.
    2. Velg en arbeidsflytkjøring.

    En hendelsestype, for eksempel push, pull_requesteller workflow_dispatch, vises øverst i sammendraget for arbeidsflytkjøring.

  • Bruk github.event_name i loggene eller i en arbeidsflyt.

    • GitHub viser kontekstdata under en arbeidsflytkjøring. Variabelen github.event_name forteller deg hvilken hendelse som utløste arbeidsflyten.

    • Du kan skrive ut informasjonen i et trinn for feilsøking:

      -name: Show event trigger
  run: echo "Triggered by ${{ github.event_name }}"

  • Bruk kjøredetaljer for arbeidsflyt:

    • Hvis du inspiserer arbeidsflytkjøringer programmatisk, for eksempel ved hjelp av API, inneholder kjøreobjektet en event egenskap som angir utløseren.
    • Du kan finne aktivering av sikker hash-algoritme (SHA), aktør og tidsstempel for å spore hva som forårsaket utløseren.

Utled utløseren fra repositoriumeffekter

Du har kanskje ikke direkte tilgang til arbeidsflytkjøringen, men du vil fortsatt utlede hva som utløste arbeidsflytkjøringen basert på repositoriumaktivitet:

Observert virkemåte Utløserhendelse
En ny utføring ble sendt til main , og arbeidsflyten ble kjørt. push begivenhet
En pull-forespørsel ble åpnet eller oppdatert. pull_request begivenhet
En bidragsyter kjørte en arbeidsflyt manuelt. workflow_dispatch
Arbeidsflyten kjører daglig på et bestemt tidspunkt. schedule (cron)
Arbeidsflyten kjørte etter et eksternt tjenesteanrop. repository_dispatch
Arbeidsflyten kjørte da en etikett eller kommentar ble lagt til i et problem. issues.* begivenhet

Ved å se gjennom tidsstempler, pull-forespørselsaktivitet og utføringslogg, kan du ofte finne ut hvilken handling som forårsaket at arbeidsflyten ble kjørt.

Slik oppsummerer du hvordan du identifiserer hva som utløste en arbeidsflyt:

  • Kontroller sammendraget for arbeidsflytkjøring på Handlinger-fanen .
  • Skriv ut eller logg i github.event_name arbeidsflyten for synlighet.
  • Sammenlign tidsstempler og repositoriumaktivitet (utfører, pull-forespørsler, problemer) for å utlede utløseren.
  • Bruk hele event konteksten for dypere undersøkelser.

Disse fremgangsmåtene hjelper deg med å feilsøke, overvåke og forbedre arbeidsflytpålitelighet på tvers av utviklings- og distribusjonssamlebånd.

Forstå en arbeidsflyteffekt ved å lese konfigurasjonsfilen

Hvis du vil forstå effektene av en arbeidsflyt fra å lese konfigurasjonsfilen, analyserer du strukturen og innholdet i .yml filen som er lagret i .github/workflows/.

Arbeidsflytkonfigurasjonsfilen angir følgende informasjon om arbeidsflyten:

  • Når den kjøres (i inndelingen on ).
  • Hva den gjør (i jobs og steps).
  • Hvor den kjører (inndelingen runs-on ).
  • Hvorfor kjører den (for eksempel testing, distribusjon eller lo).
  • Hvordan den fungerer under bestemte betingelser (miljø, filtre, logikk).

Tolke en arbeidsflyteffekt

  1. Identifiser utløseren.

    Hvis du vil identifisere hvilken handling som startet arbeidsflyten, kan du se on delen av arbeidsflyten.

    For eksempel:

    on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:

    Dette eksempelarbeidsflyten:

    • Kjører automatisk når koden sendes til hovedgrenen (push).
    • Kjører når en pull-forespørsel opprettes eller oppdateres (pull_request).
    • Kan utløses manuelt av en bruker (workflow_dispatch).

  2. Identifiser arbeidsflytjobbene og trinnene.

    Hvis du vil finne ut hva arbeidsflyten gjør, kan du se jobs og steps deler av arbeidsflyten.

    For 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 eksempelarbeidsflyten:

    • Bruker et virtuelt Linux-miljø (runs-on).
    • Sjekker ut repositoriets kode (steps>name).
    • Installerer prosjektavhengigheter (steps>name).
    • Kjører automatiserte tester (steps>name).

  3. Evaluer arbeidsflytens formål og resultat.

    Ved å lese konfigurasjonsfilen kan du beskrive det tiltenkte resultatet av arbeidsflyten:

    "Denne arbeidsflyten er et kontinuerlig integreringssamlebånd (CI). Den sikrer at enhver ny kode som sendes til repositoriet eller sendes via pull-forespørselen, testes automatisk. Hvis testene mislykkes, viser Brukergrensesnittet for GitHub-arbeidsflyt dette resultatet for å hjelpe deg med å opprettholde kodekvaliteten.»

  4. Identifiser eller angi valgfrie funksjoner som påvirker hvordan arbeidsflyten kjører:

    • env angir miljøvariabler.
    • if legger til betinget logikk for å kjøre bestemte trinn bare når vilkår oppfylles.
    • timeout-minutes eller continue-on-error angi kjøring av arbeidsflyt og feilbehandling.

Diagnostisere en mislykket arbeidsflytkjøring

  1. Gå til Handlinger-fanen i repositoriet.

  2. Finn den mislykkede kjøringen (vanligvis angitt av en rød X).

  3. Velg arbeidsflyten som ikke mislyktes, for å åpne kjøresammendraget.

  4. Se gjennom feilen i arbeidsflytloggene.

    1. Utvid hver jobb og trinn i kjøresammendraget til du finner den som angir feil.

    2. Velg jobben eller trinnet for å vise loggene.

    3. Se etter:

      • Feilmeldinger
      • Stakksporinger
      • Avslutte koder

    En mislykket test kan for eksempel vises npm ERR! Test failed eller exit code 1.

  5. Kontroller konfigurasjonsfilen for arbeidsflyten.

    .yml Bruk filen til å fastslå:

    • Hva prøvde hvert trinn å gjøre?
    • Hvis det finnes miljøvariabler (env) eller betingede (if) som påvirker kjøringen.
    • Hvis feilen skyldes manglende avhengighet, syntaksfeil eller feilkonfigurert trinn.

    Hvis et trinn mislykkes, kan du se etter følgende årsaker:

    • Ble avhengigheter installert i forrige trinn?
    • Finnes testfiler og sendes lokalt?

Vanlige feilscenarioer

Tabellen nedenfor beskriver vanlige scenarioer for arbeidsflytfeil:

Symptom Sannsynlig årsak
Et trinn mislykkes og returnerer command not foundl Manglende avhengighet eller feil oppsett
npm install Mislykkes. Skadet package-lock.json fil eller et nettverksproblem
Et testtrinn mislykkes Problemer med enhetstest, manglende konfigurasjonsfil eller ugyldig testsyntaks
Permission denied Vises. Feil filtillatelser eller manglende hemmeligheter

Identifisere hvordan du får tilgang til arbeidsflytlogger i GitHub

  1. Gå til Handlinger-fanen i repositoriet.

  2. Velg den relevante arbeidsflyten i listen over arbeidsflyter.

    Hvis filen for eksempel .yml har følgende kode, vises en kobling med tittelen CI Workflow i listen:

    name: CI Workflow

  3. Velg en bestemt kjøring.

    Velg tidsstempelet eller utføringsmeldingen for den bestemte kjøringen du vil undersøke, i listen over kjøringer som viser status.

  4. Utvid hver jobb og hvert trinn.

    Kjør sammendragssiden viser jobber slik de er definert i arbeidsflytfilen, for eksempel bygg eller test:

    1. Velg en jobb for å utvide den.
    2. Utvid individuelle trinn i jobben, for eksempel «Installer avhengigheter» eller «Kjør tester».

  5. Vis loggutdata.

    Hvis du vil vise fullstendige loggutdata, inkludert konsolllogger, feilmeldinger og feilsøkingsinformasjon, velger du et arbeidsflyttrinn. Du kan kopiere, søke etter og laste ned loggene.

Tabellen nedenfor oppsummerer trinnene du utfører for å få tilgang til arbeidsflytlogger:

Handling Hensikt
Handlinger-fanen Vis alle arbeidsflytkjøringer.
Velg arbeidsflytnavnet Filtrering kjøres etter arbeidsflyt.
Velg en kjøring Se bestemte jobb- og trinnresultater.
Utvid trinn Vis detaljerte logger.
Last ned logger Last ned logger for feilsøking i frakoblet modus eller team.

Handlingslogger for bygget

Når en arbeidsflyt kjøres, produserer den en logg som inneholder detaljer om hva som skjedde og eventuelle feil eller testfeil.

Hvis det oppstår en feil, eller hvis en test mislykkes, vises en rød X i stedet for en grønn hake i loggene. Du kan undersøke detaljene for feilen eller unnlatelsen av å undersøke hva som skjedde.

Skjermbilde av GitHub-handlingsloggen med detaljer om en mislykket test.

Arbeide med artefakter

Når en arbeidsflyt produserer noe annet enn en loggoppføring, kalles produktet en artefakt. For eksempel produserer Node.js bygg en Docker-beholder som kan distribueres. Beholderen er en artefakt som du kan laste opp til lagring ved hjelp av handlingen handlinger/opplastingsartefakt . Du kan senere laste ned artefakten fra lagring ved hjelp av handlinger/nedlastingsartefakt.

Lagring av en artefakt bevarer den mellom jobber. Hver jobb bruker en ny forekomst av en vm, slik at du ikke kan bruke artefakten på nytt ved å lagre den på VM-en. Hvis du trenger artefakten i en annen jobb, kan du laste opp artefakten til lagring i én jobb og laste den ned for den andre jobben.

Artefaktlagring

Artefakter lagres i lagringsplass på GitHub. Plassen er gratis for offentlige repositorier, og noe lagringsplass er gratis for private repositorier, avhengig av kontoen. GitHub lagrer artefaktene i 90 dager.

Legg merke til at i handlingen actions/upload-artifact@main finnes det et path attributt i følgende arbeidsflytsnutt. Verdien for dette attributtet er banen til å lagre artefakten. I dette eksemplet angir du offentlig/ for å laste opp alt til en katalog. Hvis du bare vil laste opp én enkelt fil, kan du bruke noe 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 laste ned artefakten for testing, må bygget fullføres og laste opp artefakten. I følgende kode angir du at testjobben avhenger av byggjobben.

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

I følgende arbeidsflytsnutt laster du ned artefakten. Nå kan testjobben bruke artefakten til testing.

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

Hvis du vil ha mer informasjon om hvordan du bruker artefakter i arbeidsflyter, kan du se Lagre arbeidsflytdata som artefakter.

Automatiser anmeldelser i GitHub ved hjelp av arbeidsflyter

I tillegg til å starte en arbeidsflyt via GitHub-hendelser som push og pull-request, kan du kjøre en arbeidsflyt etter en tidsplan eller etter en hendelse utenfor GitHub.

Du vil kanskje at en arbeidsflyt bare skal kjøre etter at en bruker har fullført en bestemt handling, for eksempel etter at en kontrollør godkjenner en pull-forespørsel. I dette scenarioet kan du utløse på pull-request-review.

En annen handling du kan utføre, er å legge til en etikett i pull-forespørselen. I dette tilfellet bruker du handlingen pullreminders/label-when-approved-action.

For 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 angir du miljøvariablene for handlingen. Du kan for eksempel angi antall godkjennere som kreves for å kjøre arbeidsflyten. I dette eksemplet er det ett. Godkjenningsvariabelen for secrets.GITHUB_TOKEN kreves fordi handlingen må gjøre endringer i repositoriet ved å legge til en etikett. Til slutt skriver du inn navnet på etiketten du vil legge til.

Å legge til en etikett kan være en hendelse som starter en annen arbeidsflyt, for eksempel en fletting. Vi dekker denne hendelsen i neste modul, som beskriver bruk av kontinuerlig levering i GitHub-handlinger.