Werkstromen cachen, delen en fouten opsporen

8 minuten

In deze les leert u hoe u prestaties optimaliseert, gegevens doorgeeft tussen taken en problemen met werkstromen oplost met behulp van logboeken en tokens.

Als u dit proces wilt implementeren, leert u het volgende:

Cacheafhankelijkheden voor snellere werkstromen.
Geef artefactgegevens door tussen taken.
Schakel logboekregistratie voor foutopsporing in voor werkstromen.
Werkstroomlogboeken openen vanuit de GitHub-gebruikersinterface en REST API.
Gebruik installatietokens voor GitHub App-verificatie.

Cacheafhankelijkheden met de cacheactie

Wanneer u een werkstroom bouwt, moet u vaak dezelfde uitvoer opnieuw gebruiken of afhankelijkheden van de ene uitvoering naar de andere 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. Het in de cache opslaan van afhankelijkheden vermindert de tijd die nodig is om bepaalde stappen in een werkstroom uit te voeren, omdat taken op door GitHub gehoste hardlopers elke keer in een schone virtuele omgeving beginnen.

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:

Kenmerk	Beschrijving	Verplicht
`Key`	Verwijst naar de sleutel-id die is gemaakt bij het opslaan en zoeken naar een cache.	Ja
`Path`	Verwijst naar het bestandspad op de runner om de cache of zoekopdracht uit te voeren.	Ja
`Restore-keys`	Bestaat uit alternatieve bestaande sleutels voor cache 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 van het opslaan van afhankelijkheden in de cache binnen uw werkstroom, kunt u gegevens doorgeven tussen taken binnen dezelfde werkstroom. U kunt de gegevens doorgeven 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. Deze methode is handig als u een reeks taken hebt die opeenvolgend moeten worden uitgevoerd op basis van artefacten die zijn geüpload vanuit een eerdere taak. Hiervoor moet job_2 u bijvoorbeeld job_1 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

In dit voorbeeld zijn er twee taken. job_1 schrijft tekst in het file.txt bestand. Vervolgens wordt de actions/upload-artifact@v2 actie gebruikt 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 wordt 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 bevatten standaardwerkstroomlogboeken niet voldoende details om vast te stellen waarom een specifieke werkstroomuitvoering, taak of stap mislukt. In deze scenario's kunt u meer logboekregistratie voor foutopsporing inschakelen voor twee opties: uitvoeringen en stappen. Schakel deze diagnostische logboekregistratie in door twee opslagplaatsgeheimen in te stellen waarvoor admin toegang tot de opslagplaats true vereist is.

Als u diagnostische logboekregistratie 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 in GitHub

Wanneer u nadenkt over succesvolle automatisering, wilt u de minste tijd besteden aan wat geautomatiseerd is, zodat u zich kunt richten op wat relevant is. Maar soms gaan dingen niet zoals gepland en moet u controleren wat er is gebeurd. Dat foutopsporingsproces kan frustrerend zijn.

GitHub heeft een duidelijke, gestructureerde indeling om snel tussen taken te schakelen, terwijl u de context van de huidige foutopsporingsstap behoudt.

Hoe de logboeken van een workflowuitvoering bekijken in GitHub:

Ga in uw opslagplaats naar het tabblad Acties .
Selecteer de werkstroom in het linkerdeelvenster.
In de lijst met werkstroomuitvoeringen, selecteer de uitvoering.
Selecteer de taak in Taken.
Lees de logboekuitvoer.

Als u meerdere uitvoeringen in een werkstroom hebt, kunt u het statusfilter selecteren nadat u uw werkstroom hebt geselecteerd 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 via GitHub, kunt u de GitHub REST API 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, verzendt u een GET aanvraag 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 voor het weergeven van een specifiek werkstroomrunlogboek volgt bijvoorbeeld GET dit pad:

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

Bepalen wanneer u een installatietoken van een GitHub-app gebruikt

Wanneer uw GitHub-app is geïnstalleerd op een account, kunt u deze verifiëren als app-installatie met behulp van de installation access token API-aanvragen voor REST en GraphQL. Met deze stap kan de app toegang krijgen tot resources die eigendom zijn van de installatie, ervan uitgaande dat de app de vereiste toegang en machtigingen voor de opslagplaats heeft gekregen. REST- of GraphQL API-aanvragen die zijn gedaan door een app-installatie, worden toegeschreven aan de app.

In het volgende voorbeeld vervangt u INSTALLATION_ACCESS_TOKEN met het installatietoegangstoken.

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"

U kunt ook een installatietoegangstoken gebruiken om te verifiëren voor git-toegang op basis van HTTP. Uw app moet de machtiging voor de Contents opslagplaats hebben. Vervolgens kunt u het toegangstoken voor de installatie gebruiken als het HTTP-wachtwoord.

U vervangt TOKEN in het voorbeeld door het toegangstoken voor de installatie:

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

Feedback

Is deze pagina nuttig?