Hur använder jag GitHub Actions för att skapa arbetsflöden för KI?
Här får du lära dig om GitHub Actions och arbetsflöden för KI.
Du lär dig att:
- Skapa ett arbetsflöde från en mall
- Förstå GitHub Actions-loggarna
- Köra tester mot flera mål
- Avgränsa build- och testjobb
- Spara och komma åt build-artefakter
- Automatisera etiketteringen av en pull-begäran i anslutning till en granskning
Skapa ett arbetsflöde från en mall
När du ska skapa ett arbetsflöde utgår du från en mall. En mall har vanliga jobb och steg förkonfigurerade för den specifika typ av automatisering som du implementerar. Om du inte är bekant med arbetsflöden, jobb och steg kan du läsa modulen Automatisera utvecklingsuppgifter med hjälp av GitHub Actions .
På huvudsidan för lagringsplatsen väljer du fliken Åtgärder och väljer sedan Nytt arbetsflöde.
På sidan Välj ett arbetsflöde kan du välja mellan många olika mallar. Ett exempel är mallen Node.js , som gör en ren installation av nodberoenden, skapar källkoden och kör tester för olika versioner av Node. Ett annat exempel är Python-paketmallen , som installerar Python-beroenden och kör tester, inklusive lint, i olika versioner av Python.
I sökrutan anger du Node.js.
I sökresultatet går du till fönstret Node.js och väljer Konfigurera.
Du ser det här standardarbetsflödet för Node.js mall i den nyligen skapade filen 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
Lägg märke till on:-attributet. Det här arbetsflödet utlöses vid en push-överföring till lagringsplatsen och när en pull-begäran görs mot huvudgrenen.
Det finns en job i det här arbetsflödet. Nu ska vi gå igenom vad det gör.
Attributet runs-on: anger att arbetsflödet körs på ubuntu-latest för operativsystemet. Attributet node-version: anger att det finns tre versioner, en vardera för Node version 14.x, 16.x och 18.x. Vi beskriver delen matrix på djupet senare när vi anpassar arbetsflödet.
I steps jobbet använder du åtgärden GitHub Actions /checkout@v3 för att hämta koden från lagringsplatsen till den virtuella datorn och åtgärden actions/setup-node@v3 för att konfigurera rätt version av Node.js. Vi anger att vi ska testa tre versioner av Node.js med attributet ${{ matrix.node-version }} . Det här attributet refererar till den matris som vi definierade tidigare. Attributet cache anger en pakethanterare för cachelagring i standardkatalogen.
Den sista delen av det här steget kör kommandon som används av Node.js-projektet. Kommandot npm ci installerar beroenden från filen package-lock.json, npm run build --if-present kör ett build-skript om ett sådant finns och npm test kör testramverket. Observera att den här mallen innehåller både build- och teststegen i samma jobb.
Mer information om npm finns i npm-dokumentationen:
Åtgärdsloggar för build-versionen
När ett arbetsflöde körs skapar det en logg som innehåller informationen om vad som hände och eventuella fel eller testfel.
Om det finns ett fel eller om ett test misslyckas visas en röd ✖ i stället för en grön bockmarkering ✔ i loggarna. Du kan undersöka information om felet eller om det inte gick att undersöka vad som hände.
I övningen identifierar du misslyckade tester genom att granska informationen i loggarna. Du kan komma åt loggarna från fliken Åtgärder.
Anpassa arbetsflödesmallar
I början av den här modulen beskrev vi ett scenario där du behöver konfigurera CI för ditt team. Mallen Node.js är en bra början, men du vill anpassa den så att den passar ditt eget team bättre. Du vill rikta åtgärderna mot olika versioner av Node och olika operativsystem. Du vill också att bygg- och teststegen ska vara separata jobb.
Nu ska vi se hur du anpassar ett arbetsflöde.
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
Här konfigurerade vi en build-matris för testning i flera operativsystem och språkversioner. Den här matrisen ger fyra versioner, en för varje operativsystem tillsammans med varje version av Node.
Fyra versioner, tillsammans med alla deras tester, ger en hel del logginformation. Det kan vara svårt att gå igenom allt. I följande exempel visar vi hur du flyttar teststeget till ett dedikerat testjobb. Det här jobbet testar mot flera mål. Genom att separera bygg- och teststegen blir det lättare att förstå loggen.
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
Vad är artefakter?
När ett arbetsflöde skapar något annat än en loggpost kallas produkten för en artefakt. Till exempel skapar Node.js-versionen en Docker-container som kan distribueras. Den här artefakten, containern, kan laddas upp till lagring med hjälp av åtgärdsåtgärder /uppladdningsartefakt och senare laddas ned från lagring med hjälp av åtgärdsåtgärder /download-artifact.
Om du lagrar en artefakt bevaras den mellan jobb. Varje jobb använder en ny instans av en virtuell dator (VM), så du kan inte återanvända artefakten genom att spara den på den virtuella datorn. Om du behöver artefakten i ett annat jobb kan du ladda upp artefakten till lagring i ett jobb och ladda ned den för det andra jobbet.
Lagring av artefakter
Artefakter lagras i lagringsutrymme på GitHub. Utrymmet är kostnadsfritt för offentliga lagringsplatser och en viss mängd är kostnadsfri för privata lagringsplatser, beroende på kontot. GitHub lagrar dina artefakter i 90 dagar.
Observera att det i åtgärden finns ett path: attribut i actions/upload-artifact@main följande arbetsflödesfragment. Värdet för det här attributet är sökvägen för att lagra artefakten. Här anger vi public/ för att ladda upp allt till en katalog. Om vi bara vill ladda upp en enda fil använder vi något som liknar offentliga/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/
Om du vill ladda ned artefakten för testning måste bygget slutföras och uppladdat artefakten. I följande kod anger vi att testjobbet är beroende av byggjobbet.
test:
needs: build
runs-on: ubuntu-latest
I följande arbetsflödesfragment laddar vi ned artefakten. Nu kan testjobbet använda artefakten för testning.
steps:
- uses: actions/checkout@v3
- uses: actions/download-artifact@main
with:
name: webpack artifacts
path: public
Mer information om hur du använder artefakter i arbetsflöden finns i Lagra arbetsflödesdata som artefakter i GitHub-dokumentationen.
Automatisera granskningar på GitHub med hjälp av arbetsflöden
Hittills har vi beskrivit hur du startar arbetsflödet med GitHub-händelser, till exempel push- eller pull-begäran. Vi kan också köra ett arbetsflöde enligt ett schema eller på någon händelse utanför GitHub.
Ibland vill vi bara köra arbetsflödet när en person utför en åtgärd. Vi kanske till exempel bara vill köra ett arbetsflöde när en granskare har godkänt pull-begäran. I det här scenariot kan vi utlösa arbetsflödet med pull-request-review.
En annan sak vi kan göra är att lägga till en etikett till pull-begäran. I det här exemplet använder vi åtgärden pullreminders/label-when-approved-action.
steps:
- name: Label when approved
uses: pullreminders/label-when-approved-action@main
env:
APPROVALS: "1"
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ADD_LABEL: "approved"
Lägg märke till blocket med namnet env:. I det här blocket anger du miljövariablerna för den här åtgärden. Du kan till exempel ange hur många godkännare som behövs. Här är det en. secrets.GITHUB_TOKEN Autentiseringsvariabeln krävs eftersom åtgärden måste göra ändringar i lagringsplatsen genom att lägga till en etikett. Slutligen anger du namnet på etiketten som ska läggas till.
Att lägga till en etikett kan vara en händelse som startar ett annat arbetsflöde, till exempel en sammanslagning. Vi går igenom händelsen i nästa modul om kontinuerlig leverans med GitHub Actions.