Memorarea în cache, partajarea și depanarea fluxurilor de lucru

  • 8 minute

În această unitate, veți afla cum să optimizați performanța, să transmiteți date între activități și să depanați fluxurile de lucru utilizând jurnale și tokenuri.

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

  • Dependențe cache pentru fluxuri de lucru mai rapide.
  • Treceți datele artefactelor între activități.
  • Activați înregistrarea în jurnal de depanare pentru fluxurile de lucru.
  • Jurnale de flux de lucru Access din interfața de utilizator GitHub și API-ul REST.
  • Utilizați tokenurile de instalare pentru autentificarea aplicației GitHub.

Dependențe cache cu acțiunea cache

Atunci când construiți un flux de lucru, trebuie adesea să reutilizați aceleași ieșiri sau să descărcați dependențe de la o rulare la alta. În loc să descărcați aceste dependențe din nou, le puteți memora în cache pentru a face fluxul de lucru să ruleze mai rapid și mai eficient. Dependențele de memorare în cache reduce timpul necesar pentru a rula anumiți pași într-un flux de lucru, deoarece activitățile de pe GitHub-hosted runners încep într-un mediu virtual curat de fiecare dată.

Pentru a memora dependențele în cache pentru o activitate, utilizați acțiunea cache GitHub. Această acțiune regăsește o memorie cache identificată printr-o cheie unică pe care o furnizați. Atunci când acțiunea găsește memoria cache, aceasta regăsește fișierele memorate în cache la calea pe care o configurați. Pentru a utiliza cache acțiunea, trebuie să setați câțiva parametri specifici:

Parametru Descriere Obligatoriu
Key Se referă la identificatorul cheie creat la salvarea și căutarea unui cache. Da
Path Se referă la calea de fișier de pe rulator pentru a memora în cache sau în căutare. Da
Restore-keys Este format din chei alternative existente pentru cache dacă nu se găsește cheia cache dorită. Nu 
steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

În exemplul precedent, path este setată la ~/.npm și key include sistemul de operare al rulatorului și codul hash SHA-256 al fișierului package-lock.json. Prefixarea cheii cu un ID (npm-cache în acest exemplu) este utilă atunci când utilizați restore-keys revenire și aveți mai multe memorii cache.

Treceți datele artefactelor între activități

Similar cu ideea de memorare în cache a dependențelor din fluxul de lucru, puteți transfera date între activități din interiorul aceluiași flux de lucru. Puteți transmite datele utilizând și upload-artifact acțiuniledownload-artifact. Lucrările dependente de artefactele unei lucrări anterioare trebuie să aștepte ca lucrarea anterioară să se termine cu succes înainte de a putea rula. Această abordare este utilă dacă aveți o serie de locuri de muncă care trebuie să ruleze secvențial pe baza artefactelor încărcate dintr-o lucrare anterioară. De exemplu, job_2 necesită job_1 utilizând sintaxa de needs: job_1.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

Acest exemplu are două lucrări. job_1 scrie text în file.txt fișier. Apoi utilizează acțiunea actions/upload-artifact@v2 pentru a încărca acest artefact și a stoca datele pentru utilizare ulterioară în fluxul de lucru. job_2 necesită job_1 pentru a se finaliza utilizând sintaxa de needs: job_1. Apoi utilizează acțiunea de actions/download-artifact@v2 pentru a descărca acel artefact, apoi imprimați conținutul file.txt.

Activarea înregistrării în jurnal a depanarea pașilor într-un flux de lucru

În unele cazuri, jurnalele implicite de flux de lucru nu oferă suficiente detalii pentru a diagnostica motivul pentru care o anumită rulare, activitate sau pas nu reușește. În aceste scenarii, puteți activa înregistrarea în jurnal a mai multor depanări pentru două opțiuni: rulează și pașii. Activați această înregistrare în jurnal de diagnosticare setând două secrete de depozit care necesită admin acces la depozit la true.

  • Pentru a activa rularea înregistrării în jurnalul de diagnosticare, setați secretul ACTIONS_RUNNER_DEBUG în depozitul care conține fluxul de lucru la true.
  • Pentru a activa înregistrarea în jurnal a diagnosticului în pași, setați secretul ACTIONS_STEP_DEBUG în depozitul care conține fluxul de lucru pentru a true.

Accesarea jurnalelor de flux de lucru în GitHub

Atunci când vă gândiți la automatizarea reușită, urmăriți să petreceți cel mai puțin timp privind ceea ce este automatizat, astfel încât să vă puteți concentra asupra a ceea ce este relevant. Dar uneori lucrurile nu merg așa cum am planificat și trebuie să revizuiți ce s-a întâmplat. Acest proces de depanare poate fi frustrant.

GitHub are un aspect structurat clar, care vă ajută să vă deplasați rapid între activități, păstrând contextul pasului curent de depanare.

Pentru a vizualiza jurnalele unui flux de lucru rulat în GitHub:

  1. În depozit, accesați fila Acțiuni .
  2. În panoul din stânga, selectați fluxul de lucru.
  3. În lista de rulări ale fluxului de lucru, selectați rularea.
  4. Sub Lucrări, selectați activitatea.
  5. Citiți rezultatul jurnalului.

Dacă aveți mai multe rulări într-un flux de lucru, puteți să selectați filtrul Stare după ce selectați fluxul de lucru și să-l setați la Eroare pentru a afișa doar rulările nereușite în acel flux de lucru.

Accesarea jurnalelor de flux de lucru din API-ul REST

Pe lângă vizualizarea jurnalelor prin GitHub, puteți utiliza API-ul REST GitHub pentru a vizualiza jurnalele pentru rulează fluxul de lucru, a rula din nou fluxurile de lucru sau chiar a anula rulările fluxului de lucru. Pentru a vizualiza jurnalul unui flux de lucru rulat utilizând API-ul, trimiteți o GET solicitare la punctul final al jurnalelor. Rețineți că orice persoană care are acces de citire la depozit poate utiliza acest punct final. Dacă depozitul este privat, trebuie să utilizați un token de acces cu domeniul repo.

De exemplu, o GET solicitare de a vizualiza un anumit jurnal de rulare a fluxului de lucru urmează această cale:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Identificați când să utilizați un token de instalare dintr-o aplicație GitHub

Atunci când aplicația dvs. GitHub este instalată într-un cont, o puteți autentifica ca instalare de aplicație utilizând installation access token solicitările API REST și GraphQL. Acest pas permite aplicației să acceseze resursele deținute de instalare, presupunând că aplicația a primit accesul și permisiunile necesare pentru depozit. SOLICITĂRILE REST sau GraphQL efectuate de o instalare de aplicație sunt atribuite aplicației.

În exemplul următor, înlocuiți INSTALLATION_ACCESS_TOKEN cu simbolul de acces de instalare:

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

De asemenea, puteți utiliza un token de acces de instalare pentru autentificarea pentru accesul Git bazat pe HTTP. Aplicația dvs. trebuie să aibă permisiunea depozitului Contents . Apoi puteți utiliza tokenul de acces de instalare ca parolă HTTP.

TOKEN Înlocuiți în exemplu cu simbolul de acces la instalare:

git clone https://x-access-token:TOKEN@github.com/owner/repo.git