Cachelagrar, delar och felsöker arbetsflöden

8 minuter

I den här lektionen får du lära dig hur du optimerar prestanda, skickar data mellan jobb och felsöker arbetsflöden med hjälp av loggar och token.

Om du vill implementera den här processen får du lära dig att:

Cacheberoenden för snabbare arbetsflöden.
Skicka artefaktdata mellan jobb.
Aktivera felsökningsloggning för arbetsflöden.
Få åtkomst till arbetsflödesloggar från GitHub-användargränssnittet och REST-API:et.
Använd installationstoken för GitHub App-autentisering.

Cacheberoenden med cacheåtgärden

När du skapar ett arbetsflöde behöver du ofta återanvända samma utdata eller ladda ned beroenden från en körning till en annan. I stället för att ladda ned dessa beroenden om och om igen kan du cachelagrar dem så att arbetsflödet körs snabbare och effektivare. Cachelagring av beroenden minskar den tid det tar att köra vissa steg i ett arbetsflöde, eftersom jobb på GitHub-värdar startar i en ren virtuell miljö varje gång.

Om du vill cachelagrar beroenden för ett jobb använder du GitHubs cache åtgärd. Den här åtgärden hämtar en cache som identifieras av en unik nyckel som du anger. När åtgärden hittar cachen hämtar den sedan de cachelagrade filerna till den sökväg som du konfigurerar. Om du vill använda åtgärden cache måste du ange några specifika parametrar:

Parameter	Beskrivning	Krävs
`Key`	Refererar till nyckelidentifieraren som skapas när du sparar och söker efter en cache.	Ja
`Path`	Refererar till filsökvägen på löparen för cachelagring eller sökning.	Ja
`Restore-keys`	Består av alternativa befintliga nycklar för cachelagring om den önskade cachenyckeln inte hittas.	Nej

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 föregående exempel path är inställt på ~/.npm och key innehåller löparens operativsystem och SHA-256-hash för package-lock.json filen. Att prefixa nyckeln med ett ID (npm-cache i det här exemplet) är användbart när du använder återställningen restore-keys och har flera cacheminnen.

Skicka artefaktdata mellan jobb

På samma sätt som tanken på cachelagring av beroenden i arbetsflödet kan du skicka data mellan jobb i samma arbetsflöde. Du kan skicka data genom att använda åtgärderna upload-artifact och download-artifact. Jobb som är beroende av ett tidigare jobbs artefakter måste vänta tills det tidigare jobbet har slutförts innan de kan köras. Den här metoden är användbar om du har en serie jobb som måste köras sekventiellt baserat på artefakter som laddats upp från ett tidigare jobb. Kräver till exempel job_2job_1 med hjälp av syntaxen 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

Det här exemplet har två jobb. job_1 skriver lite text i file.txt filen. Sedan används åtgärden actions/upload-artifact@v2 för att ladda upp den här artefakten och lagra data för framtida användning i arbetsflödet. job_2 måste job_1 slutföras med hjälp av syntaxen needs: job_1 . Sedan används åtgärden actions/download-artifact@v2 för att ladda ned artefakten och sedan skriva ut innehållet i file.txt.

Aktivera stegfelsökningsloggning i ett arbetsflöde

I vissa fall ger standardarbetsflödesloggar inte tillräckligt med information för att du ska kunna diagnostisera varför en specifik arbetsflödeskörning, ett jobb eller ett visst steg misslyckas. I dessa scenarier kan du aktivera mer felsökningsloggning för två inställningar: körningar och steg. Aktivera den här diagnostikloggningen genom att ange två lagringsplatshemligheter som kräver admin åtkomst till lagringsplatsen till true.

Om du vill aktivera körningsdiagnostikloggning anger du hemligheten ACTIONS_RUNNER_DEBUG på lagringsplatsen som innehåller arbetsflödet till true.
Om du vill aktivera stegdiagnostikloggning anger du hemligheten ACTIONS_STEP_DEBUG på lagringsplatsen som innehåller arbetsflödet till true.

Få åtkomst till arbetsflödesloggarna i GitHub

När du tänker på en lyckad automatisering vill du ägna minst tid åt att titta på vad som är automatiserat så att du kan fokusera på det som är relevant. Men ibland går saker inte som planerat, och du måste granska vad som hände. Den felsökningsprocessen kan vara frustrerande.

GitHub har en tydlig, strukturerad layout som hjälper dig att snabbt flytta mellan jobb medan du behåller kontexten för det aktuella felsökningssteget.

Så här visar du loggarna för ett arbetsflöde som körs i GitHub:

Gå till fliken Åtgärder på lagringsplatsen.
Välj arbetsflödet i den vänstra rutan.
I listan över arbetsflödeskörningar väljer du körningen.
Under Jobb väljer du jobbet.
Läs loggutdata.

Om du har flera körningar i ett arbetsflöde kan du välja filtret Status när du har valt arbetsflödet och ställa in det på Fel om du bara vill visa misslyckade körningar i arbetsflödet.

Komma åt arbetsflödesloggarna från REST-API:et

Förutom att visa loggar via GitHub kan du använda GitHub REST API för att visa loggar för arbetsflödeskörningar, köra arbetsflöden igen eller till och med avbryta arbetsflödeskörningar. Om du vill visa en arbetsflödeskörningslogg med hjälp av API:et skickar du en GET begäran till loggslutpunkten. Tänk på att alla med läsåtkomst till lagringsplatsen kan använda den här slutpunkten. Om lagringsplatsen är privat måste du använda en åtkomsttoken med omfånget repo .

En begäran om att visa en specifik arbetsflödeskörningslogg följer till exempel GET den här sökvägen:

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

Identifiera när du ska använda en installationstoken från en GitHub-app

När din GitHub-app är installerad på ett konto kan du autentisera den som en appinstallation med hjälp av installation access token för REST- och GraphQL API-begäranden. Det här steget gör att appen kan komma åt resurser som ägs av installationen, förutsatt att appen har beviljats nödvändig åtkomst och behörighet för lagringsplatsen. REST- eller GraphQL API-begäranden som görs av en appinstallation tillskrivs appen.

I följande exempel ersätter INSTALLATION_ACCESS_TOKEN du med installationsåtkomsttoken:

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 också använda en installationsåtkomsttoken för att autentisera för HTTP-baserad Git-åtkomst. Appen måste ha lagringsplatsens Contents behörighet. Du kan sedan använda installationsåtkomsttoken som HTTP-lösenord.

Du ersätter TOKEN i exemplet med installationsåtkomsttoken:

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

Feedback

Var den här sidan till hjälp?