Gestionarea și depanarea fluxurilor de lucru în Acțiuni GitHub

10 minute

Rețineți că obiectivul dvs. este să automatizați procesul de generare și publicare a codului, astfel încât caracteristicile să fie actualizate de fiecare dată când un dezvoltator adaugă o modificare la baza de cod.

Pentru a implementa acest proces, veți afla cum să:

Identificați evenimentul care a declanșat un flux de lucru.
Utilizați jurnale de flux de lucru Acțiuni GitHub.
Salvați și accesați artefactele de construire.
Automatizați adăugarea unei etichete la o solicitare de extragere după o revizuire.

Identificați evenimentul care a declanșat un flux de lucru

Înțelegerea a ceea ce a declanșat un flux de lucru acțiuni GitHub este esențial pentru depanarea, auditarea și îmbunătățirea canalelor CI/CD. Tipul de triggere includ o împingere la o ramură, o solicitare de tragere creată sau actualizată, o activitate planificată sau un dispecerat manual. Puteți identifica evenimentul care declanșează prin examinarea rulării fluxului de lucru, a modificărilor depozitului și a problemei asociate cu GitHub sau prin solicitarea de extragere.

Diagramă care afișează diferite triggere de flux de lucru în acțiuni GitHub, cum ar fi împingere, solicitare de tragere, planificare și expediere manuală.

Ce este un declanșator de flux de lucru?

Un declanșator de flux de lucru este un eveniment care determină rularea unui flux de lucru. GitHub acceptă diverse tipuri de triggere, inclusiv:

push sau pull_request (pe baza modificărilor de cod)
workflow_dispatch (un declanșator manual)
schedule (lucrări cron)
repository_dispatch (sisteme externe)
Problemă, discuție și evenimente de solicitare de extragere (de exemplu, issues.opened, pull_request.closed)

Identificați evenimentul declanșator

Puteți identifica un eveniment declanșator de flux de lucru în mai multe moduri:

Utilizați interfața de utilizator a acțiunilor GitHub:
1. În depozit, selectați fila Acțiuni .
2. Selectați un flux de lucru care rulează.
Un tip de eveniment, cum pushar fi , pull_requestsau workflow_dispatch, apare în partea de sus a rezumatului rulării fluxului de lucru.
Utilizați github.event_name în jurnale sau într-un flux de lucru.
- GitHub expune date contextuale în timpul rulării unui flux de lucru. Variabila github.event_name vă spune ce eveniment a declanșat fluxul de lucru.
- Puteți imprima informațiile într-un pas pentru depanare:
```
-name: Show event trigger
  run: echo "Triggered by ${{ github.event_name }}"
```
Utilizarea detaliilor de rulare a fluxului de lucru:
- Dacă inspectați fluxul de lucru rulează programatic, cum ar fi prin utilizarea API, obiectul de rulare include o event proprietate care specifică declanșatorul.
- Puteți găsi algoritmul de comitere Secure Hash Algorithm (SHA), actorul și marca de timp pentru a urmări ceea ce a cauzat declanșatorul.

Deduci declanșatorul din efectele depozitului

Este posibil să nu aveți acces direct la rularea fluxului de lucru, dar tot doriți să deduci ce a declanșat rularea fluxului de lucru pe baza activității de depozit:

Comportament observat	Eveniment de declanșare
S-a împins o nouă comitere și `main` fluxul de lucru a rulat.	`push` eveniment
O solicitare de tragere a fost deschisă sau actualizată.	`pull_request` eveniment
Un colaborator a rulat manual un flux de lucru.	`workflow_dispatch`
Fluxul de lucru rulează zilnic la un anumit moment.	`schedule` (cron)
Fluxul de lucru a rulat după un apel de serviciu extern.	`repository_dispatch`
Fluxul de lucru a rulat atunci când o etichetă sau un comentariu a fost adăugat la o problemă.	`issues.*` eveniment

Prin revizuirea marcajului de timp, a activității de extragere și a istoricului de comitere, puteți adesea să identificați ce acțiune a determinat rularea fluxului de lucru.

Pentru a rezuma cum să identificați ce a declanșat un flux de lucru:

Verificați rezumatul rulării fluxului de lucru pe fila Acțiuni .
Imprimați sau conectați-vă github.event_name în interiorul fluxului de lucru pentru vizibilitate.
Comparați marcajele de timp și activitatea de depozit (comiteri, solicitări de tragere, probleme) pentru a deduce declanșatorul.
Utilizați contextul complet event pentru o investigație mai profundă.

Aceste practici vă ajută să depanați, să auditați și să îmbunătățiți fiabilitatea fluxului de lucru în versiunile de dezvoltare și implementare.

Înțelegerea unui efect de flux de lucru citindu-i fișierul de configurare

Pentru a înțelege efectele unui flux de lucru de la citirea fișierului de configurare, analizați structura și conținutul fișierului .yml stocat în .github/workflows/.

Fișierul de configurare a fluxului de lucru specifică următoarele informații despre fluxul de lucru:

Când rulează (în on secțiune).
Ce face (în jobs și steps).
Unde rulează (secțiunea runs-on ).
De ce rulează (scopul său, cum ar fi testarea, implementarea sau delincierea).
Cum se comportă în anumite condiții (mediu, filtre, logică).

Interpretarea unui efect de flux de lucru

Identificați declanșatorul.

Pentru a identifica ce acțiune a inițiat fluxul de lucru, consultați secțiunea on a fluxului de lucru.

De exemplu:
```
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:
```
Acest exemplu de flux de lucru:
- Rulează automat atunci când codul este împins la ramura principală (push).
- Rulează atunci când se creează sau se actualizează o solicitare de tragere (pull_request).
- Poate fi declanșat manual de un utilizator (workflow_dispatch).
Identificați activitățile și pașii fluxului de lucru.

Pentru a determina ce face fluxul de lucru, consultați jobs secțiunile și steps secțiunile fluxului de lucru.

De exemplu:
```
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
```
Acest exemplu de flux de lucru:
- Utilizează un mediu virtual Linux (runs-on).
- Extrage codul depozitului (steps>name).
- Instalează dependențele de proiect (steps>name).
- Rulează teste automate (steps>name).
Evaluați scopul și rezultatul fluxului de lucru.

Prin citirea fișierului de configurare, puteți descrie rezultatul intenționat al fluxului de lucru:

"Acest flux de lucru este o conductă de integrare continuă (CI). Se asigură că orice cod nou care este trimis în depozit sau remis prin solicitarea de tragere este testat automat. Dacă testele nu reușesc, interfața de utilizator a fluxului de lucru GitHub afișează acest rezultat pentru a vă ajuta să mențineți calitatea codului."
Identificați sau setați caracteristici opționale care afectează modul în care rulează fluxul de lucru:
- env setează variabile de mediu.
- if adaugă logică condițională pentru a rula pași specifici doar atunci când sunt îndeplinite criteriile.
- timeout-minutes sau continue-on-error setați executarea fluxului de lucru și gestionarea erorilor.

Diagnosticarea unei rulări nereușită a fluxului de lucru

În depozit, accesați fila Acțiuni .
Găsiți rularea eșuată (de obicei indicată printr-un X roșu).
Selectați fluxul de lucru nereușit pentru a deschide rezumatul rulării.
În jurnalele de flux de lucru, revizuiți eroarea.
1. În rezumatul rulării, extindeți fiecare activitate și pas până când îl găsiți pe cel care indică eroarea.
2. Selectați activitatea sau pasul pentru a-i vizualiza jurnalele.
3. Caută:
  - Mesaje de eroare
  - Urme de stivă
  - Coduri de ieșire
De exemplu, un test nereușit poate afișa npm ERR! Test failed sau exit code 1.
Verificați fișierul de configurare a fluxului de lucru.

.yml Utilizați fișierul pentru a determina:
- Ce a fost fiecare pas în încercarea de a face?
- Dacă există variabile de mediu (env) sau condiționale (if) care afectează execuția.
- Dacă eroarea este cauzată de o dependență lipsă, o eroare de sintaxă sau un pas configurat greșit.
Dacă un pas nu reușește, verificați următoarele cauze:
- Dependențele au fost instalate cu succes în pasul precedent?
- Fișierele de test există și trec local?

Scenarii de eroare comune

Următorul tabel descrie scenariile uzuale de eroare a fluxului de lucru:

Symptom	Cauza probabilă
Un pas nu reușește și returnează `command not found`l	Lipsește dependența sau configurarea greșită
`npm install` Nu reuşeşte.	Fișier deteriorat `package-lock.json` sau problemă de rețea
Un pas de test nu reușește	Probleme de testare a unității, fișier de configurare lipsă sau sintaxă de test nevalidă
`Permission denied` Apare.	Permisiuni incorecte pentru fișiere sau secrete lipsă

Identificați cum să accesați jurnalele de flux de lucru în GitHub

În depozit, accesați fila Acțiuni .
În lista de fluxuri de lucru, selectați fluxul de lucru relevant.

De exemplu, dacă fișierul are .yml următorul cod, în listă apare un link intitulat Flux de lucru CI :
```
name: CI Workflow
```
Selectați o anumită rulare.

În lista de rulări care afișează starea, selectați marca de timp sau mesajul de comitere a rulării specifice pe care doriți să o inspectați.
Extindeți fiecare activitate și pas.

Pagina de rulare rezumat afișează activitățile așa cum sunt definite în fișierul flux de lucru, cum ar fi compilarea sau testarea:
1. Selectați o activitate pentru a o extinde.
2. În cadrul activității, extindeți pași individuali, cum ar fi "Instalarea dependențelor" sau "Rulați teste".
Vizualizare ieșire jurnal.

Pentru a vizualiza ieșirea completă a jurnalului, inclusiv jurnalele de consolă, mesajele de eroare și informațiile de depanare, selectați un pas de flux de lucru. Puteți să copiați, să căutați și să descărcați jurnalele.

Următorul tabel rezumă pașii pe care îi urmați pentru a accesa jurnalele de flux de lucru:

Action	Purpose
Fila Acțiuni	Vizualizați toate rulările fluxului de lucru.
Selectați numele fluxului de lucru	Filtrul rulează după fluxul de lucru.
Selectați o rulare	Vedeți rezultate specifice ale activității și pașilor.
Extindeți pașii	Vizualizați jurnalele detaliate.
Descărcați jurnalele	Descărcați jurnalele pentru depanarea offline sau a echipei.

Jurnale de acțiune pentru compilare

Atunci când un flux de lucru rulează, produce un jurnal care include detaliile despre ceea ce s-a întâmplat și orice erori sau erori de test.

Dacă apare o eroare sau dacă un test nu reușește, apare un X roșu în loc de un marcaj de selectare verde în jurnale. Puteți examina detaliile erorii sau erorii pentru a investiga ce s-a întâmplat.

Captură de ecran a jurnalului acțiunilor GitHub cu detalii într-un test nereușit.

Lucrul cu artefactele

Când un flux de lucru produce altceva decât o intrare de jurnal, produsul se numește artefact. De exemplu, versiunea Node.js produce un container Docker care poate fi implementat. Containerul este un artefact pe care îl puteți încărca în stocare utilizând acțiunea actions/upload-artifact . Ulterior, puteți descărca artefactul din stocare utilizând actions/download-artifact.

Stocarea unui artefact îl păstrează între activități. Fiecare lucrare utilizează o instanță nouă a unei mașini virtuale, astfel încât să nu puteți reutiliza artefactul salvându-l pe VM. Dacă aveți nevoie de artefactul dvs. într-o altă lucrare, puteți să încărcați artefactul în spațiul de stocare într-o singură lucrare și să-l descărcați pentru cealaltă lucrare.

Depozitarea artefactelor

Artefactele sunt stocate în spațiul de stocare de pe GitHub. Spațiul este gratuit pentru depozitele publice, iar unele depozite sunt gratuite pentru depozite private, în funcție de cont. GitHub stochează artefactele timp de 90 de zile.

În următorul fragment de flux de lucru, observați că în acțiunea de actions/upload-artifact@main există un atribut path. Valoarea acestui atribut este calea de stocare a artefactului. În acest exemplu, specificați public/ pentru a încărca totul într-un director. Dacă doriți să încărcați doar un singur fișier, utilizați ceva de genul public/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/

Pentru a descărca artefactul pentru testare, compilarea trebuie să se termine cu succes și să încarce artefactul. În următorul cod, specificați că activitatea de testare depinde de activitatea de compilare.

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

În următorul fragment de flux de lucru, descărcați artefactul. Acum, lucrarea de testare poate utiliza artefactul pentru testare.

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

Pentru mai multe informații despre utilizarea artefactelor în fluxurile de lucru, consultați Stocarea datelor fluxului de lucru ca artefacte.

Automatizarea recenziilor în GitHub utilizând fluxuri de lucru

Pe lângă pornirea unui flux de lucru prin evenimente GitHub, cum ar fi push și pull-request, puteți rula un flux de lucru într-o planificare sau după un eveniment în afara GitHub.

Poate doriți ca un flux de lucru să ruleze numai după ce un utilizator termină o anumită acțiune, cum ar fi după ce un recenzent aprobă o solicitare de extragere. Pentru acest scenariu, puteți să declanșați pe pull-request-review.

O altă acțiune pe care o puteți efectua este să adăugați o etichetă la solicitarea de extragere. În acest caz, utilizați acțiunea pullreminders/label-when-approved-action.

De exemplu:

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

În bloc env , setați variabilele de mediu pentru acțiune. De exemplu, puteți seta numărul de aprobatori necesari pentru a rula fluxul de lucru. În acest exemplu, este unul. Variabila de autentificare secrets.GITHUB_TOKEN este necesară, deoarece acțiunea trebuie să efectueze modificări la depozit, adăugând o etichetă. În sfârșit, introduceți numele etichetei de adăugat.

Adăugarea unei etichete poate fi un eveniment care începe un alt flux de lucru, cum ar fi o îmbinare. Vom acoperi acest eveniment în modulul următor, care descrie utilizarea livrării continue în Acțiuni GitHub.

Feedback

Această pagină a fost utilă?