Hoe gebruik ik GitHub Actions om werkstromen voor CI te maken?

Voltooid

Hier vindt u informatie over GitHub Actions en werkstromen voor CI.

U leert het volgende:

• Een werkstroom maken op basis van een sjabloon
• Informatie over de GitHub Actions-logboeken
• Testen tegen meerdere doelwitten
• Afzonderlijke build- en testtaken
• Buildartefacten opslaan en openen
• Automatiseer het labelen van een PR bij een review

Een werkstroom maken op basis van een sjabloon

Als u een werkstroom wilt maken, begint u met een sjabloon. Een sjabloon bevat algemene taken en stappen die vooraf zijn geconfigureerd voor het specifieke type automatisering dat u implementeert. Als u niet bekend bent met werkstromen, taken en stappen, bekijkt u de Ontwikkeltaken automatiseren met behulp van gitHub Actions module.

Selecteer op de hoofdpagina van uw opslagplaats het tabblad Acties en selecteer vervolgens Nieuwe werkstroom.

Op de pagina Een werkstroom kiezen kunt u kiezen uit veel verschillende sjablonen. Een voorbeeld is de Node.js-sjabloon, waarmee een schone installatie van knooppuntafhankelijkheden wordt uitgevoerd, de broncode wordt gebouwd en tests worden uitgevoerd voor verschillende versies van Node. Een ander voorbeeld is het Python-pakket sjabloon, waarmee Python-afhankelijkheden worden geïnstalleerd en tests worden uitgevoerd, waaronder lint, in verschillende versies van Python.

Voer in het zoekvak Node.jsin.

Selecteer in de zoekresultaten, in het deelvenster Node.js, Configureren.

U ziet deze standaardwerkstroom voor Node.js sjabloon in het zojuist gemaakte bestand node.js.yml.

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Let op het kenmerk on:. Deze werkstroom wordt geactiveerd bij een push naar de repository en wanneer er een pull request wordt gedaan tegen de hoofdbranch.

Er is één job in deze workflow. Laten we eens kijken wat het doet.

Het kenmerk runs-on: geeft aan dat de werkstroom voor het besturingssysteem wordt uitgevoerd op ubuntu-latest. Het kenmerk node-version: geeft aan dat er drie builds zijn, één voor Node versie 14.x, 16.x en 18.x. We beschrijven het matrix gedeelte later uitgebreid, wanneer we de werkstroom aanpassen.

De steps in de taak gebruikt de GitHub Actions actions/checkout@v3-actie om de code van uw opslagplaats op te halen in de virtuele machine en de acties/setup-node@v3-actie om de juiste versie van Node.jsin te stellen. We geven aan dat we drie versies van Node.js gaan testen met het kenmerk ${{ matrix.node-version }}. Dit kenmerk verwijst naar de matrix die we eerder hebben gedefinieerd. Het kenmerk cache geeft een pakketbeheerder op voor caching in de standaardmap.

In het laatste deel van deze stap worden opdrachten uitgevoerd die worden gebruikt door Node.js projecten. Met de opdracht npm ci worden afhankelijkheden uit het package-lock.json-bestand geïnstalleerd, npm run build --if-present een buildscript uitvoert als dit bestaat en npm test het testframework uitvoert. U ziet dat deze sjabloon zowel de build- als teststappen in dezelfde taak bevat.

Raadpleeg de npm-documentatie voor meer informatie over npm:

• npm installeren
• npm uitvoeren
• npm-test

Actielogboeken voor de build

Wanneer een werkstroom wordt uitgevoerd, wordt er een logboek gegenereerd met de details van wat er is gebeurd en eventuele fouten of testfouten.

Als er een fout optreedt of als een test mislukt, ziet u een rood ✖ in plaats van een groen vinkje ✔ in de logboeken. U kunt de details van de fout bekijken om te onderzoeken wat er is gebeurd.

In de oefening identificeert u mislukte tests door de details in de logboeken te bekijken. U kunt de logboeken openen via het tabblad Acties.

Werkstroomsjablonen aanpassen

Aan het begin van deze module hebben we een scenario beschreven waarin u CI moet instellen voor uw team. De Node.js sjabloon is een goed begin, maar u wilt deze aanpassen aan de vereisten van uw eigen team. U wilt zich richten op verschillende versies van Node en verschillende besturingssystemen. U wilt ook dat de build- en teststappen afzonderlijke taken zijn.

Laten we eens kijken hoe u een werkstroom aanpast.

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

Hier hebben we een buildmatrix geconfigureerd voor het testen van meerdere besturingssystemen en taalversies. Deze matrix produceert vier builds, één voor elk besturingssysteem dat is gekoppeld aan elke versie van Node.

Vier builds, samen met al hun tests, produceren nogal wat logboekgegevens. Het kan lastig zijn om alles te sorteren. In het volgende voorbeeld laten we u zien hoe u de teststap verplaatst naar een toegewezen testtaak. Deze taak test tegen meerdere doelen. Door de build- en teststappen te scheiden, is het eenvoudiger om het logboek te begrijpen.

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true

Wat zijn artefacten?

Wanneer een werkstroom iets anders produceert dan een logboekvermelding, wordt het product een artefactgenoemd. De Node.js build produceert bijvoorbeeld een Docker-container die kan worden geïmplementeerd. Dit artifact, de container, kan worden geüpload naar de opslag met behulp van de actie actions/upload-artifact en later gedownload uit de opslag met behulp van de actie actions/download-artifact.

Een artefact opslaan zorgt ervoor dat het behouden blijft tussen taken. Elke taak maakt gebruik van een nieuw exemplaar van een virtuele machine (VM), zodat u het artefact niet opnieuw kunt gebruiken door het op de virtuele machine op te slaan. Als u uw artefact in een andere taak nodig hebt, kunt u het artefact uploaden naar de opslag in de ene taak en het voor de andere taak downloaden.

Artefactopslag

Artefacten worden opgeslagen in opslagruimte op GitHub. De ruimte is gratis voor openbare opslagplaatsen en een bepaalde hoeveelheid is gratis voor privéopslagplaatsen, afhankelijk van het account. GitHub slaat uw artefacten 90 dagen op.

In het volgende werkstroomfragment ziet u dat er in de actions/upload-artifact@main actie een path: kenmerk is. De waarde van dit kenmerk is het pad voor het opslaan van het artefact. Hier geven we openbare/ op om alles te uploaden naar een map. Als we slechts één bestand willen uploaden, gebruiken we iets als openbare/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Als u het artefact wilt downloaden voor testen, moet de build met succes voltooid zijn en het artefact geüpload zijn. In de volgende code geven we op dat de testtaak afhankelijk is van de buildtaak.

test:
    needs: build
    runs-on: ubuntu-latest

In het volgende werkstroomfragment downloaden we het artefact. Nu kan de testtaak het artefact gebruiken om te testen.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

Zie Werkstroomgegevens opslaan als artefacten in de GitHub-documentatie voor meer informatie over het gebruik van artefacten in werkstromen.

Beoordelingen automatiseren in GitHub met behulp van werkstromen

Tot nu toe hebben we beschreven hoe u de workflow start met GitHub-gebeurtenissen, zoals push- of pull-request. We kunnen ook een werkstroom uitvoeren volgens een planning of op een gebeurtenis buiten GitHub.

Soms willen we de werkstroom alleen uitvoeren nadat een persoon een actie heeft uitgevoerd. We willen bijvoorbeeld alleen een werkstroom uitvoeren nadat een revisor de pull-aanvraag goedkeurt. Voor dit scenario kunnen we pull-request-reviewtriggeren.

Een andere actie die we kunnen ondernemen, is het toevoegen van een label aan de pull-aanvraag. In dit geval gebruiken we de pullreminders/label-when-approved-action actie.

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

Let op het blok met de naam env:. In dit blok stelt u de omgevingsvariabelen voor deze actie in. U kunt bijvoorbeeld het aantal fiatteurs instellen dat nodig is. Hier is er één. De secrets.GITHUB_TOKEN verificatievariabele is vereist omdat de actie wijzigingen moet aanbrengen in uw opslagplaats door een label toe te voegen. Ten slotte geeft u de naam op van het label dat u wilt toevoegen.

Het toevoegen van een label kan een gebeurtenis zijn die een andere werkstroom start, zoals een samenvoeging. We behandelen deze gebeurtenis in de volgende module over continue levering met GitHub Actions.