Hur automatiserar GitHub-åtgärder utvecklingsuppgifter?

Slutförd

Här introducerar vi GitHub Actions och arbetsflöden. Du får lära dig vilka typer av åtgärder du kan använda och var du hittar dem. Du kommer också att titta på exempel på dessa typer av åtgärder och hur de passar i ett arbetsflöde.

GitHub minskar tiden från idé till distribution

GitHub är framtaget för att hjälpa grupper med utvecklare och DevOps-tekniker att snabbt skapa och distribuera program. Det finns många funktioner i GitHub för detta, vanligtvis i någon av följande två kategorier:

• Kommunikation: Överväg alla sätt som GitHub gör det enkelt för ett team med utvecklare att kommunicera om programvaruutvecklingsprojektet: kodgranskningar i pull-begäranden, GitHub-problem, projekttavlor, wikis, meddelanden och så vidare.
• Automation: Med GitHub Actions kan ditt team automatisera arbetsflöden i varje steg i programutvecklingsprocessen, från integrering till leverans till distribution. Du kan till och med automatisera att lägga till etiketter för att hämta begäranden och söka efter inaktuella problem och pull-begäranden.

När de kombineras har dessa funktioner gjort det möjligt för tusentals utvecklingsteam att effektivt minska den tid det tar från den första idén till distributionen.

Använda arbetsflödesautomation för att minska utvecklingstiden

Vi fokuserar på automatisering i den här modulen, så låt oss ta en stund att förstå hur team kan använda automatisering för att minska den tid det tar att slutföra ett typiskt arbetsflöde för utveckling och distribution.

Tänk på alla uppgifter som måste utföras när koden har skrivits, men innan du på ett tillförlitligt sätt kan använda koden för dess avsedda syfte. Beroende på organisationens mål behöver du förmodligen utföra en eller flera av följande uppgifter:

• Kontrollera att koden skickar alla enhetstester
• Utföra kvalitets- och efterlevnadskontroller av kod för att se till att källkoden uppfyller organisationens standarder
• Kontrollera koden och dess beroenden efter kända säkerhetsproblem
• Skapa koden och integrera en ny källa från (potentiellt) flera deltagare
• Kontrollera att programvaran skickar integrationstester
• Skapa en ny version
• Leverera de nya binärfilerna till lämplig plats i filsystemet
• Distribuera de nya binärfilerna till en eller flera servrar
• Om någon av dessa uppgifter inte godkänns rapporterar du problemet till rätt individ eller team för lösning

Utmaningen är att utföra dessa uppgifter på ett tillförlitligt, konsekvent och hållbart sätt. Det här är ett perfekt jobb för automatisering av arbetsflöden. Om du redan förlitar dig på GitHub vill du förmodligen konfigurera arbetsflödesautomationen med GitHub Actions.

Vad är GitHub Actions?

GitHub Actions är paketerade skript för att automatisera uppgifter i ett arbetsflöde för programvaruutveckling i GitHub. Du kan konfigurera GitHub Actions för att utlösa komplexa arbetsflöden som uppfyller organisationens behov. varje gång utvecklare kontrollerar ny källkod i en viss gren, vid tidsintervall eller manuellt. Resultatet är ett tillförlitligt och hållbart automatiserat arbetsflöde, vilket leder till en betydande minskning av utvecklingstiden.

Var hittar du GitHub Actions?

GitHub Actions är skript som följer yml-dataformatet. Varje lagringsplats har fliken Åtgärder som ger ett snabbt och enkelt sätt att komma igång med att konfigurera ditt första skript. Om du ser ett arbetsflöde som du tror kan vara en bra startpunkt väljer du bara knappen Konfigurera för att lägga till skriptet och börja redigera käll-yml.

Utöver de GitHub Actions som finns på fliken Åtgärder kan du även:

• Söka efter GitHub Actions på GitHub Marketplace. På GitHub Marketplace kan du hitta och köpa verktyg som utökar ditt arbetsflöde.
• Söka efter projekt med öppen källkod. Till exempel har GitHub Actions-organisationen många populära lagringsplatser med öppen källkod som innehåller GitHub Actions som du kan använda.
• Skriva dina egna GitHub Actions från grunden. Om du vill kan du också ge dem öppen källkod, eller till och med publicera dem på GitHub Marketplace.

Använda GitHub Actions med öppen källkod

Många GitHub Actions är öppen källkod och tillgängliga för alla som vill använda dem. Men precis som med alla program med öppen källkod måste du noggrant kontrollera dem innan du använder dem i projektet. På samma sätt som rekommenderade communitystandarder med programvara med öppen källkod, till exempel readme, uppförandekod, bidragande fil och ärendemallar, bara för att nämna några, kan du följa dessa rekommendationer när du använder GitHub Actions:

• Granska åtgärdens action.yml fil för indata, utdata och se till att koden gör vad den säger att den gör.
• Kontrollera om åtgärden finns på GitHub Marketplace. Det här är en bra kontroll, även om en åtgärd inte behöver finnas på GitHub Marketplace för att vara giltig.
• Kontrollera om åtgärden har verifierats på GitHub Marketplace. Det innebär att GitHub har godkänt användningen av den här åtgärden. Du bör dock fortfarande granska den innan du använder den.
• Inkludera den version av åtgärden som du använder genom att ange en Git ref, SHA eller tagg.

Typer av GitHub-åtgärder

Det finns tre typer av GitHub-åtgärder: containeråtgärder, JavaScript-åtgärder och sammansatta åtgärder.

Med containeråtgärder är miljön en del av åtgärdens kod. De här åtgärderna kan bara köras i en Linux-miljö med GitHub som värd. Behållaråtgärder har stöd för många olika språk.

JavaScript-åtgärder inkluderar inte miljön i koden. Du måste ange miljön för att utföra dessa åtgärder. Du kan köra dessa åtgärder på en virtuell dator i molnet eller lokalt. JavaScript-åtgärder stöder Linux-, macOS- och Windows-miljöer.

Med sammansatta åtgärder kan du kombinera flera arbetsflödessteg inom en åtgärd. Du kan till exempel använda den här funktionen för att paketera flera körningskommandon i en åtgärd och sedan ha ett arbetsflöde som kör de paketerade kommandona som ett enda steg med den åtgärden.

En GitHub-åtgärds anatomi

Här är ett exempel på en åtgärd som utför en git-utcheckning av en lagringsplats. Den här åtgärden, åtgärder/checkout@v1, är en del av ett steg i ett arbetsflöde. Det här steget skapar också Node.js kod som har checkats ut. Vi ska prata om arbetsflöden, jobb och steg i nästa avsnitt.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

Anta att du vill använda en containeråtgärd för att köra containerkod. Din åtgärd kan se ut så här:

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Lägg märke till området inputs. Här får du värdet för en variabel med namnet MY_NAME. Den här variabeln anges i arbetsflödet som kör den här åtgärden.

Observera att du anger Dockerruns i attributet i området uses. När du gör det måste du ange sökvägen till Docker-avbildningsfilen. Här kallas det Dockerfile. Vi går inte in på detaljerna i Docker här, men om du vill ha mer information kan du läsa modulen Introduktion till Docker-containrar .

Det sista avsnittet, lägg till varumärke, anpassar din åtgärd i GitHub Marketplace om du vill publicera den där.

Du hittar en fullständig lista över åtgärds-metadata i Metadata-syntax för GitHub Actions.

Vad är ett GitHub Actions-arbetsflöde?

Ett GitHub Actions-arbetsflöde är en process som du konfigurerar på lagringsplatsen för att automatisera livscykeluppgifter för programvaruutveckling, inklusive GitHub Actions. Med ett arbetsflöde kan du skapa, testa, paketera, släppa och distribuera alla projekt på GitHub.

Om du vill skapa ett arbetsflöde lägger du till åtgärder i en .yml-fil i katalogen .github/workflows på din GitHub-lagringsplats.

I den kommande övningen ser arbetsflödesfilen main.yml ut så här:

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

Lägg märke till on:-attributet. Detta är en utlösare för att ange när det här arbetsflödet ska köras. Här utlöses en körning när det finns en push-händelse till din lagringsplats. Du kan ange enskilda händelser som on: push, en matris med händelser som on: [push, pull_request]eller en händelsekonfigurationskarta som schemalägger ett arbetsflöde eller begränsar körningen av ett arbetsflöde till specifika filer, taggar eller grenändringar. Kartan kan se ut ungefär så här:

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

En händelse utlöses på alla aktivitetstyper för händelsen om du inte anger typen eller typerna. En omfattande lista över händelser och deras aktivitetstyper finns i: Händelser som utlöser arbetsflöden i GitHub-dokumentationen.

Ett arbetsflöde måste ha minst ett jobb. Ett jobb är ett avsnitt i arbetsflödet som är associerat med en löpare. En löpare kan vara GitHub-värdbaserad eller lokalt installerad och jobbet kan köras på en dator eller i en container. Du anger löparen med attributet runs-on: . Här uppmanar du arbetsflödet att köra det här jobbet på ubuntu-latest.

Varje jobb kommer att ha steg att slutföra. I vårt exempel använder steget åtgärdsåtgärder /checkout@v1 för att checka ut lagringsplatsen. Det intressanta är uses: ./action-a värdet, som är sökvägen till containeråtgärden som du skapar i en action.yml fil. Vi tittade på innehållet i en action.yml-fil i avsnittet Vad är GitHub Actions?

Den sista delen av den här arbetsflödesfilen anger MY_NAME variabelvärdet för det här arbetsflödet. Kom ihåg att containeråtgärden tog indata med namnet MY_NAME.

Mer information om arbetsflödessyntax finns i Arbetsflödessyntax för GitHub Actions

GitHub-värdbaserade och lokalt installerade löpare

Vi nämnde kort löpare som associerade med ett jobb. En löpare är helt enkelt en server som har GitHub Actions-löparprogrammet installerat. I föregående arbetsflödesexempel fanns det ett runs-on: ubuntu-latest attribut i jobbblocket som berättade för arbetsflödet att jobbet ska köras med den GitHub-värdbaserade löparen som körs i ubuntu-latest miljön.

När det gäller löpare finns det två alternativ att välja mellan: GitHub-värdbaserade löpare eller lokalt installerade löpare. Om du använder en GitHub-värdbaserad löpare körs varje jobb i en ny instans av en virtuell miljö som anges av den GitHub-värdbaserade löpare som du definierar, runs-on: {operating system-version}. Med lokalt installerade löpare måste du använda etiketten med egen värd, dess operativsystem och systemarkitekturen. Till exempel skulle en lokalt installerad löpare med ett Linux-operativsystem och ARM32-arkitektur se ut så här: runs-on: [self-hosted, linux, ARM32].

Varje typ av löpare har sina fördelar, men GitHub-värdbaserade löpare erbjuder ett snabbare och enklare sätt att köra dina arbetsflöden, om än med begränsade alternativ. Lokalt installerade löpare är ett mycket konfigurerbart sätt att köra arbetsflöden i din egen anpassade lokala miljö. Du kan köra lokalt installerade löpare lokalt eller i molnet. Du kan också använda lokalt installerade löpare för att skapa en anpassad maskinvarukonfiguration med mer bearbetningskraft eller minne för att köra större jobb, installera programvara som är tillgänglig i ditt lokala nätverk och välja ett operativsystem som inte erbjuds av GitHub-värdbaserade löpare.

GitHub Actions kan innehålla användningsgränser

GitHub Actions har vissa användningsgränser, beroende på din GitHub-plan och om din löpare är GitHub-värdbaserad eller lokalt installerad. Mer information om användningsgränser finns i Användningsgränser, fakturering och administration i GitHub-dokumentationen.