Hurtigbufre, dele og feilsøke arbeidsflyter

  • 8 minutter

I denne enheten lærer du hvordan du optimaliserer ytelsen, sender data mellom jobber og feilsøker arbeidsflyter ved hjelp av logger og tokener.

Hvis du vil implementere denne prosessen, lærer du hvordan du gjør følgende:

  • Hurtigbufferavhengigheter for raskere arbeidsflyter.
  • Send artefaktdata mellom jobber.
  • Aktiver feilsøkingslogging for arbeidsflyter.
  • Access-arbeidsflytlogger fra GitHub-brukergrensesnittet og REST-API-en.
  • Bruk installasjonstokener for GitHub App-godkjenning.

Hurtigbufferavhengigheter med hurtigbufferhandlingen

Når du bygger ut en arbeidsflyt, må du ofte bruke de samme utdataene eller laste ned avhengigheter fra én kjøring til en annen. I stedet for å laste ned disse avhengighetene om og om igjen, kan du bufre dem for å få arbeidsflyten til å kjøre raskere og mer effektivt. Hurtigbufring av avhengigheter reduserer tiden det tar å kjøre bestemte trinn i en arbeidsflyt, fordi jobber på GitHub-vertsbaserte løpere starter i et rent virtuelt miljø hver gang.

Hvis du vil bufre avhengigheter for en jobb, kan du bruke GitHubs cache handling. Denne handlingen henter en hurtigbuffer identifisert av en unik nøkkel du oppgir. Når handlingen finner hurtigbufferen, henter den deretter de bufrede filene til banen du konfigurerer. Hvis du vil bruke cache handlingen, må du angi noen bestemte parametere:

Parameter Beskrivelse Obligatorisk
Key Refererer til nøkkelidentifikatoren som ble opprettet når du lagrer og søker etter en hurtigbuffer. Ja
Path Refererer til filbanen på løperen for å bufre eller søke. Ja
Restore-keys Består av alternative eksisterende nøkler til hurtigbufferen hvis den ønskede hurtigbuffernøkkelen ikke blir funnet. Nei 
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-

I det foregående eksemplet er path satt til ~/.npm, og key inkluderer løperens operativsystem og SHA-256-hash-koden for package-lock.json-filen. Det er nyttig å prefikse nøkkelen med en ID (npm-cache i dette eksemplet) når du bruker restore-keys tilbakefall og har flere hurtigbuffere.

Sende artefaktdata mellom jobber

På samme måte som ideen om hurtigbufring av avhengigheter i arbeidsflyten, kan du sende data mellom jobber i samme arbeidsflyt. Du kan sende dataene ved hjelp upload-artifact av og download-artifact -handlingene. Jobber som er avhengige av en tidligere jobbs artefakter, må vente til den forrige jobben fullføres før de kan kjøres. Denne fremgangsmåten er nyttig hvis du har en rekke jobber som må kjøre sekvensielt basert på artefakter lastet opp fra en tidligere jobb. job_2 krever for eksempel job_1 ved hjelp av needs: job_1 syntaks.

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

Dette eksemplet har to jobber. job_1 skriver tekst i file.txt filen. Deretter bruker den actions/upload-artifact@v2 til å laste opp denne artefakten og lagre dataene for fremtidig bruk i arbeidsflyten. job_2 krever at job_1 fullføres ved hjelp av needs: job_1-syntaksen. Den bruker deretter handlingen actions/download-artifact@v2 til å laste ned artefakten, og deretter skrive ut innholdet i file.txt.

Aktiver trinnsøklogging i en arbeidsflyt

I noen tilfeller gir ikke standard arbeidsflytlogger nok detaljer for deg til å diagnostisere hvorfor en bestemt arbeidsflytkjøring, jobb eller trinn mislykkes. I disse scenariene kan du aktivere mer feilsøkingslogging for to alternativer: kjøringer og trinn. Aktiver denne diagnoseloggingen ved å angi to repositoriumhemmeligheter som krever admin tilgang til repositoriet til true.

  • Hvis du vil aktivere kjøring av ACTIONS_RUNNER_DEBUG diagnoselogging, angir du hemmeligheten i repositoriet som inneholder arbeidsflyten true.
  • Hvis du vil aktivere trinndiagnoselogging, angir du ACTIONS_STEP_DEBUG hemmelighet i repositoriet som inneholder arbeidsflyten, til true.

Få tilgang til arbeidsflytloggene i GitHub

Når du tenker på vellykket automatisering, tar du sikte på å bruke minst tid på å se på hva som er automatisert, slik at du kan fokusere på det som er relevant. Men noen ganger går ikke ting som planlagt, og du må se gjennom hva som skjedde. Denne feilsøkingsprosessen kan være frustrerende.

GitHub har et klart, strukturert oppsett som hjelper deg med raskt å flytte mellom jobber, samtidig som du beholder konteksten for det gjeldende feilsøkingstrinnet.

Slik viser du loggene for en arbeidsflytkjøring i GitHub:

  1. Gå til Handlinger-fanen i repositoriet.
  2. Velg arbeidsflyten i den venstre ruten.
  3. Velg kjøringen i listen over arbeidsflytkjøringer.
  4. Velg jobben under Jobber.
  5. Les loggutdataene.

Hvis du har flere kjøringer i en arbeidsflyt, kan du velge Status-filteret etter at du har valgt arbeidsflyten, og angi at den ikke kan vise bare mislykkede kjøringer i arbeidsflyten.

Få tilgang til arbeidsflytloggene fra REST-API-en

I tillegg til å vise logger via GitHub, kan du bruke GItHub REST-API-en til å vise logger for arbeidsflytkjøringer, kjøre arbeidsflyter på nytt eller til og med avbryte arbeidsflytkjøringer. Hvis du vil vise loggen for en arbeidsflytkjøring ved hjelp av API-en, sender du en GET forespørsel til loggendepunktet. Husk at alle med lesetilgang til repositoriet kan bruke dette endepunktet. Hvis repositoriet er privat, må du bruke et tilgangstoken med repo omfang.

En forespørsel om å vise en bestemt arbeidsflytkjøringslogg følger for eksempel GET denne banen:

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

Identifisere når du skal bruke et installasjonstoken fra en GitHub-app

Når GitHub-appen er installert på en konto, kan du godkjenne den som en appinstallasjon ved hjelp installation access token av API-forespørslene REST og GraphQL. Dette trinnet gir appen tilgang til ressurser som eies av installasjonen, forutsatt at appen ble gitt nødvendig tilgang til repositorium og tillatelser. REST- eller GraphQL API-forespørsler fra en appinstallasjon tilskrives appen.

I eksemplet nedenfor erstatter INSTALLATION_ACCESS_TOKEN du med installasjonstilgangstokenet:

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"

Du kan også bruke et tilgangstoken for installasjon til å godkjenne for HTTP-basert Git-tilgang. Appen må ha tillatelsen Contents repositorium. Deretter kan du bruke installasjonstilgangstokenet som HTTP-passord.

Du erstatter TOKEN i eksemplet med installasjonstilgangstokenet:

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