Anpassa arbetsflödet med miljövariabler och artefaktdata

  • 12 minuter

Här får du lära dig hur du använder standardvariabler och anpassade miljövariabler, anpassade skript, cacheberoenden och skickar artefaktdata mellan jobb. Du får också lära dig hur du kommer åt arbetsflödesloggarna från både GitHub-webbplatsen och REST API-slutpunkterna.

Standardmiljövariabler och kontexter

I GitHub Actions-arbetsflödet finns det flera standardmiljövariabler som du kan använda, men bara inom den löpare som kör ett jobb. Dessa standardvariabler är skiftlägeskänsliga och refererar till konfigurationsvärden för systemet och för den aktuella användaren. Vi rekommenderar att du använder dessa standardmiljövariabler för att referera till filsystemet i stället för att använda hårdkodade filsökvägar. Om du vill använda en standardmiljövariabel anger du $ följt av miljövariabelns namn.

jobs:
  prod-check:
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

Förutom standardmiljövariabler kan du använda definierade variabler som kontexter. Kontexter och standardvariabler är liknande eftersom de båda ger åtkomst till miljöinformation, men de har några viktiga skillnader. Standardmiljövariabler kan endast användas inom löparen, men kontextvariabler kan användas när som helst i arbetsflödet. Med kontextvariabler kan du till exempel köra en if -instruktion för att utvärdera ett uttryck innan löparen körs.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

Det här exemplet använder kontexten github.ref för att kontrollera grenen som utlöste arbetsflödet. Om grenen är mainkörs löparen och skriver ut "Distribuera till produktionsservern på grenen $GITHUB_REF". Standardmiljövariabeln $GITHUB_REF används i löparen för att referera till grenen. Observera att standardmiljövariabler är versaler där kontextvariabler alla är gemener.

Anpassade miljövariabler

På samma sätt som med standardmiljövariabler kan du använda anpassade miljövariabler i arbetsflödesfilen. Om du vill skapa en anpassad variabel måste du definiera den i arbetsflödesfilen med hjälp av kontexten env . Om du vill använda värdet för en miljövariabel i en löpare kan du använda runner-operativsystemets normala metod för att läsa miljövariabler.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        env:
          First_Name: Mona

Skript i arbetsflödet

I föregående exempel på arbetsflödesfragment används nyckelordet run för att helt enkelt skriva ut en textsträng. Eftersom nyckelordet run instruerar jobbet att köra ett kommando på löparen använder du nyckelordet run för att köra åtgärder eller skript.

jobs:
  example-job:
    steps:
      - run: npm install -g bats

I det här exemplet använder du npm för att installera bats programvarutestningspaketet med hjälp av nyckelordet run . Du kan också köra ett skript som en åtgärd. Du kan lagra skriptet på lagringsplatsen, som ofta görs i en .github/scripts/ katalog, och sedan ange sökvägen och gränssnittstypen med hjälp av nyckelordet run .

jobs:
  example-job:
    steps:
      - name: Run build script
        run: ./.github/scripts/build.sh
        shell: bash

Cacheberoenden med cacheåtgärden

När du skapar ett arbetsflöde ser du ofta behovet av att å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. Detta kan avsevärt minska den tid det tar att köra vissa steg i ett arbetsflöde, eftersom jobb på GitHub-värdbaserade löpare startar i en ren virtuell miljö varje gång. Cachelagringsberoenden hjälper till att påskynda den tid det tar att återskapa dessa beroendefiler.

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 Obligatoriskt
Nyckel Refererar till nyckelidentifieraren som skapas när du sparar och söker efter en cache. Ja
Sökväg Refererar till filsökvägen på löparen för cachelagring eller sökning. Ja
Återställningsnycklar består av alternativa befintliga nycklar till cacheminnen 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 göra detta med hjälp upload-artifact av åtgärderna 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. Det här är användbart 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_2 job_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

Föregående exempel har två jobb. job_1 skriver lite text i filen file.txt och använder actions/upload-artifact@v2 sedan åtgärden 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 actions/download-artifact@v2 och använder sedan åtgärden 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ödesloggarna inte tillräckligt med information för att diagnostisera varför en specifik arbetsflödeskörning, ett jobb eller ett visst steg har misslyckats. I dessa situationer kan du aktivera ytterligare felsökningsloggning för två alternativ: 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 från användargränssnittet

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 din uppmärksamhet 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, men GitHub tillhandahåller en tydlig layoutstruktur som gör det möjligt att snabbt navigera mellan jobben samtidigt som kontexten för felsökningssteget bevaras. Om du vill visa loggarna för ett arbetsflöde som körs i GitHub kan du följa dessa steg:

  1. Gå till fliken Åtgärder på lagringsplatsen.
  2. Klicka på önskat arbetsflöde i det vänstra sidofältet.
  3. Välj önskad körning i listan över arbetsflödeskörningar.
  4. Under Jobb väljer du önskat jobb.
  5. Läs loggutdata.

Om du har flera körningar i ett arbetsflöde kan du också 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 med GitHub kan du också använda GitHubs 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 måste du skicka en GET begäran till loggarnas slutpunkt. 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 skulle till exempel GET följa den här sökvägen:

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