Hoe gebruik ik GitHub-acties om workflows voor CI te maken?
Hier leert u meer over GitHub-acties en workflows voor CI.
U leert het volgende:
- Maak een workflow vanuit een sjabloon
- Meer informatie over de GitHub actions-logboeken
- Testen op meerdere doelen
- Aparte bouw- en testopdrachten
- Bewaar en open build-artefacten
- Automatiseer het labelen van een PR bij beoordeling
Maak een workflow vanuit een sjabloon
Om een workflow te creëren, 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 de 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 de Python-pakketsjabloon , waarmee Python-afhankelijkheden worden geïnstalleerd en tests worden uitgevoerd, waaronder lint, in verschillende versies van Python.
Voer in het zoekvak Node.js in.
Selecteer Configureren in de zoekresultaten in het deelvenster Node.js.
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 tijdens een push naar de opslagplaats en wanneer er een pull-aanvraag wordt gedaan op basis van de hoofdbranch.
Er is er een job in deze werkstroom. Laten we eens kijken wat het doet.
Het kenmerk runs-on: geeft aan dat de workflow voor het besturingssysteem wordt uitgevoerd op ubuntu-latest. Het node-version: kenmerk geeft aan dat er drie builds zijn, één voor Node-versie 14.x, 16.x en 18.x. We beschrijven het matrix gedeelte verderop, wanneer we de werkstroom aanpassen.
De steps in de taak maakt gebruik van de Acties van GitHub Actions /checkout@v3 actie om de code op te halen uit uw opslagplaats in de VIRTUELE machine en de acties/setup-node@v3 actie om de juiste versie van Node.js in te stellen. We geven aan dat we drie versies van Node.js gaan testen met het ${{ matrix.node-version }} kenmerk. Dit kenmerk verwijst naar de matrix die we eerder hebben gedefinieerd. Het cache kenmerk geeft een pakketbeheerder op voor caching in de standaardmap.
Het laatste deel van deze stap voert opdrachten uit die worden gebruikt door Node.js-projecten. Het npm ci commando installeert afhankelijkheden van het pakket-lock.json -bestand, npm run build --if-present voert een build-script uit als het bestaat, en npm test voert het testraamwerk uit. U ziet dat deze sjabloon zowel de bouw- als teststappen in dezelfde taak bevat.
Raadpleeg de npm-documentatie voor meer informatie over npm:
Actielogboeken voor de build
Wanneer een workflow wordt uitgevoerd, wordt er een logboek gemaakt 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 of niet onderzoeken wat er is gebeurd.
In de oefening identificeert u mislukte tests door de details in de logboeken te controleren. 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 verschillende versies van het knooppunt en andere besturingssystemen richten. U wilt ook dat de build- en teststappen afzonderlijke taken zijn.
Laten we eens kijken hoe u een workflow aanpast.
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
Hier hebben we een build-matrix geconfigureerd voor testen in 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 artefact genoemd. De Node.js-build produceert bijvoorbeeld een Docker-container die kan worden geïmplementeerd. Dit artefact, de container, kan worden geüpload naar de opslag met behulp van de actieacties /upload-artefacten en later gedownload uit de opslag met behulp van de actieacties /download-artifact.
Als u een artefact opslaat, blijft het tussen taken behouden. 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.
Artefact opslag
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 naar een map te uploaden. Als we slechts één bestand willen uploaden, gebruiken we iets als openbaar/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 zijn voltooid en het artefact geüpload. 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.
Automatiseer beoordelingen in GitHub met behulp van workflows
Tot nu toe hebben we beschreven hoe u de werkstroom start met GitHub-gebeurtenissen, zoals push- of pull-aanvraag. 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-reviewactiveren.
Een andere actie die we kunnen ondernemen, is een label toevoegen aan het pull-verzoek. In dit geval gebruiken we de actie pullreminders/label-when-goedgekeurd-Action.
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 benodigde goedkeurders instellen. Hier is het 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.