Uw werkstroom aanpassen met omgevingsvariabelen en artefactgegevens

12 minuten

Hier leert u hoe u standaard- en aangepaste omgevingsvariabelen, aangepaste scripts, cacheafhankelijkheden en artefactgegevens tussen taken doorgeeft. U leert ook hoe u toegang krijgt tot de werkstroomlogboeken vanaf zowel de GitHub-website als de REST API-eindpunten.

Standaardomgevingsvariabelen en contexten

In de GitHub Actions-werkstroom zijn er verschillende standaardomgevingsvariabelen beschikbaar die u kunt gebruiken, maar alleen binnen de runner die een taak uitvoert. Deze standaardvariabelen zijn hoofdlettergevoelig en ze verwijzen naar configuratiewaarden voor het systeem en voor de huidige gebruiker. U wordt aangeraden deze standaardomgevingsvariabelen te gebruiken om naar het bestandssysteem te verwijzen in plaats van naar vaste bestandspaden te gebruiken. Als u een standaardomgevingsvariabele wilt gebruiken, geeft u $ de naam van de omgevingsvariabele op gevolgd door de naam van de omgevingsvariabele.

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

Naast de standaardomgevingsvariabelen kunt u gedefinieerde variabelen als contexten gebruiken. Contexten en standaardvariabelen zijn vergelijkbaar omdat ze beide toegang bieden tot omgevingsgegevens, maar ze hebben enkele belangrijke verschillen. Hoewel standaardomgevingsvariabelen alleen binnen de runner kunnen worden gebruikt, kunnen contextvariabelen op elk moment in de werkstroom worden gebruikt. Met contextvariabelen kunt u bijvoorbeeld een if instructie uitvoeren om een expressie te evalueren voordat de runner wordt uitgevoerd.

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"

In dit voorbeeld wordt de context gebruikt om de github.ref vertakking te controleren die de werkstroom heeft geactiveerd. Als de vertakking is main, wordt de runner uitgevoerd en wordt 'Implementeren naar productieserver op vertakking $GITHUB_REF' afgedrukt. De standaardomgevingsvariabele $GITHUB_REF wordt gebruikt in de runner om naar de vertakking te verwijzen. U ziet dat standaardomgevingsvariabelen allemaal hoofdletters zijn waarbij contextvariabelen allemaal kleine letters bevatten.

Aangepaste omgevingsvariabelen

Net als bij het gebruik van standaardomgevingsvariabelen kunt u aangepaste omgevingsvariabelen gebruiken in uw werkstroombestand. Als u een aangepaste variabele wilt maken, moet u deze definiëren in uw werkstroombestand met behulp van de env context. Als u de waarde van een omgevingsvariabele in een runner wilt gebruiken, kunt u de normale methode van het runner-besturingssysteem gebruiken voor het lezen van omgevingsvariabelen.

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

Scripts in uw werkstroom

In de voorgaande voorbeelden van werkstroomfragmenten wordt het run trefwoord gebruikt om gewoon een tekenreeks met tekst af te drukken. Omdat het run trefwoord aangeeft dat de taak een opdracht op de runner moet uitvoeren, gebruikt u het run trefwoord om acties of scripts uit te voeren.

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

In dit voorbeeld gebruikt u npm om het bats softwaretestpakket te installeren met behulp van het run trefwoord. U kunt ook een script uitvoeren als een actie. U kunt het script opslaan in uw opslagplaats, vaak uitgevoerd in een .github/scripts/ map en vervolgens het pad en shelltype opgeven met behulp van het run trefwoord.

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

Cacheafhankelijkheden met de cacheactie

Wanneer u een werkstroom bouwt, zult u vaak dezelfde uitvoer opnieuw moeten gebruiken of afhankelijkheden van de ene uitvoering naar de andere moeten downloaden. In plaats van deze afhankelijkheden telkens opnieuw te downloaden, kunt u ze in de cache opslaan om uw werkstroom sneller en efficiënter uit te voeren. Dit kan de tijd die nodig is om bepaalde stappen in een werkstroom uit te voeren aanzienlijk verminderen, omdat taken op door GitHub gehoste hardlopers elke keer in een schone virtuele omgeving beginnen. Het in de cache opslaan van afhankelijkheden helpt de tijd die nodig is om deze afhankelijkheidsbestanden opnieuw te maken.

Als u afhankelijkheden voor een taak in de cache wilt opslaan, gebruikt u de actie van cache GitHub. Met deze actie wordt een cache opgehaald die wordt geïdentificeerd door een unieke sleutel die u opgeeft. Wanneer de actie de cache vindt, worden de bestanden in de cache opgehaald naar het pad dat u configureert. Als u de cache actie wilt gebruiken, moet u enkele specifieke parameters instellen:

Parameter	Omschrijving	Vereist
Sleutel	Verwijst naar de sleutel-id die is gemaakt bij het opslaan en zoeken naar een cache.	Ja
Pad	Verwijst naar het bestandspad op de runner om de cache of zoekopdracht uit te voeren.	Ja
Herstelsleutels	bestaat uit alternatieve bestaande sleutels voor caches als de gewenste cachesleutel niet wordt gevonden.	Nee

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-

In het voorgaande voorbeeld is het path ingesteld op ~/.npm en bevat het key besturingssysteem van de runner en de SHA-256-hash van het package-lock.json bestand. Het voorvoegsel van de sleutel met een id (npm-cache in dit voorbeeld) is handig wanneer u de restore-keys terugval gebruikt en meerdere caches hebt.

Artefactgegevens doorgeven tussen taken

Net als bij het idee dat afhankelijkheden in de cache in uw werkstroom worden opgeslagen, kunt u gegevens doorgeven tussen taken binnen dezelfde werkstroom. U kunt dit doen met behulp van de upload-artifact en download-artifact acties. Taken die afhankelijk zijn van de artefacten van een vorige taak, moeten wachten totdat de vorige taak is voltooid voordat ze kunnen worden uitgevoerd. Dit is handig als u een reeks taken hebt die opeenvolgend moeten worden uitgevoerd op basis van artefacten die zijn geüpload vanuit een vorige taak. Hiervoor moet job_1 u bijvoorbeeld job_2 de needs: job_1 syntaxis gebruiken.

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

Het voorgaande voorbeeld heeft twee taken. job_1 schrijft tekst naar het bestand file.txt en gebruikt vervolgens de actions/upload-artifact@v2 actie om dit artefact te uploaden en de gegevens op te slaan voor toekomstig gebruik in de werkstroom. job_2 moet job_1 worden voltooid met behulp van de needs: job_1 syntaxis, vervolgens de actions/download-artifact@v2 actie gebruikt om dat artefact te downloaden en vervolgens de inhoud van file.txt.

Fouten opsporen in logboekregistratie in een werkstroom inschakelen

In sommige gevallen bieden de standaardwerkstroomlogboeken niet voldoende details om vast te stellen waarom een specifieke werkstroomuitvoering, taak of stap is mislukt. Voor deze situaties kunt u extra logboekregistratie voor foutopsporing inschakelen voor twee opties: uitvoeringen en stappen. Schakel deze diagnostische logboekregistratie in door twee opslagplaatsgeheimen in te stellen waarvoor toegang tot de opslagplaats is vereist admin voor true:

Als u diagnostische logboekregistratie van runners wilt inschakelen, stelt u het ACTIONS_RUNNER_DEBUG geheim in de opslagplaats in waarop de werkstroom zich bevindt true.
Als u diagnostische logboekregistratie van stappen wilt inschakelen, stelt u het ACTIONS_STEP_DEBUG geheim in de opslagplaats in waarop de werkstroom zich bevindt true.

Toegang tot de werkstroomlogboeken vanuit de gebruikersinterface

Wanneer u nadenkt over succesvolle automatisering, wilt u de minste tijd besteden aan wat geautomatiseerd is, zodat u uw aandacht kunt richten op wat relevant is. Maar soms gaan dingen niet zoals gepland en moet u controleren wat er is gebeurd. Dit foutopsporingsproces kan frustrerend zijn, maar GitHub biedt een duidelijke indelingsstructuur waarmee u snel tussen de taken kunt navigeren terwijl de context van de huidige foutopsporingsstap behouden blijft. Als u de logboeken van een werkstroom wilt bekijken die wordt uitgevoerd in GitHub, voert u de volgende stappen uit:

Navigeer naar het tabblad Acties in uw opslagplaats.
Klik in de linkerzijbalk op de gewenste werkstroom.
Selecteer in de lijst met werkstroomuitvoeringen de gewenste uitvoering.
Selecteer onder Taken de gewenste taak.
Lees de logboekuitvoer.

Als u meerdere uitvoeringen in een werkstroom hebt, kunt u ook het statusfilter selecteren nadat u uw werkstroom hebt gekozen en deze instellen op Fout om alleen de mislukte uitvoeringen in die werkstroom weer te geven.

Toegang tot de werkstroomlogboeken vanuit de REST API

Naast het weergeven van logboeken met GitHub, kunt u ook de REST API van GitHub gebruiken om logboeken weer te geven voor werkstroomuitvoeringen, werkstromen opnieuw uit te voeren of zelfs werkstroomuitvoeringen te annuleren. Als u het logboek van een werkstroomuitvoering wilt weergeven met behulp van de API, moet u een GET aanvraag verzenden naar het eindpunt van de logboeken. Houd er rekening mee dat iedereen met leestoegang tot de opslagplaats dit eindpunt kan gebruiken. Als de opslagplaats privé is, moet u een toegangstoken met het repo bereik gebruiken.

Een aanvraag om een specifiek werkstroomuitvoeringslogboek weer te geven, volgt bijvoorbeeld GET dit pad:

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