Hvordan automatiserer GitHub-handlinger utviklingsoppgaver?

  • 10 minutter

Her introduserer vi GitHub-handlinger og arbeidsflyter. Du lærer hvilke typer handlinger du kan bruke, og hvor du finner dem. Du ser også på eksempler på disse typene handlinger og hvordan de passer inn i en arbeidsflyt.

GitHub reduserer tiden fra idé til distribusjon

GitHub er utformet for å hjelpe team av utviklere og DevOps-ingeniører med å bygge og distribuere programmer raskt. Det finnes mange funksjoner i GitHub som aktiverer disse effektivitetene, men de faller vanligvis inn i én av to kategorier:

  • Communication: Vurder alle måtene GitHub gjør det enkelt for et team av utviklere å kommunisere om programvareutviklingsprosjektet: kodegjennomganger i pull-forespørsler, GitHub-problemer, prosjekttavler, wikier, varsler og så videre.
  • Automatisering: GitHub Actions lar teamet automatisere arbeidsflyter på hvert trinn i programvareutviklingsprosessen, fra integrering til levering til distribusjon. Den lar deg til og med automatisere å legge til etiketter for å hente forespørsler og se etter foreldede problemer og pull-forespørsler.

Når de kombineres, har disse funksjonene gjort det mulig for tusenvis av utviklingsteam å effektivt redusere tiden det tar fra deres første idé til distribusjon.

Bruk arbeidsflytautomatisering til å redusere utviklingstiden

I denne modulen fokuserer vi på automatisering. La oss ta deg tid til å forstå hvordan team kan bruke automatisering for å redusere tiden det tar å fullføre en typisk arbeidsflyt for utvikling og distribusjon.

Vurder alle oppgavene som må skje etter at koden er skrevet, men før du kan bruke koden på en pålitelig måte til det tiltenkte formålet. Avhengig av organisasjonens mål må du sannsynligvis utføre én eller flere av følgende oppgaver:

  • Kontroller at koden består alle enhetstester.
  • Utfør kodekvalitet og samsvarskontroller for å sikre at kildekoden oppfyller organisasjonens standarder.
  • Kontroller koden og avhengighetene for kjente sikkerhetsproblemer.
  • Bygg koden ved å integrere ny kildekode fra (potensielt) flere bidragsytere.
  • Sørg for at programvaren består integreringstester.
  • Angi versjonen av det nye bygget.
  • Lever de nye binærfilene til riktig filsystemplassering.
  • Distribuer de nye binærfilene til én eller flere servere.
  • Bestem om noen av disse oppgavene ikke passerer, og rapporter problemet til riktig enkeltperson eller team for løsning.

Utfordringen er å gjøre disse oppgavene pålitelig, konsekvent og på en bærekraftig måte. Denne prosessen er en ideell jobb for automatisering av arbeidsflyt. Hvis du allerede er avhengig av GitHub, vil du sannsynligvis konfigurere arbeidsflytautomatisering ved hjelp av GitHub-handlinger.

Hva er GitHub-handlinger?

GitHub-handlinger er pakkede skript for å automatisere oppgaver i en arbeidsflyt for programvareutvikling i GitHub. Du kan konfigurere GitHub-handlinger til å utløse komplekse arbeidsflyter som oppfyller organisasjonens behov. Utløseren kan skje hver gang utviklere sjekker ny kildekode inn i en bestemt gren, med tidsbestemte intervaller eller manuelt. Resultatet er en pålitelig og bærekraftig automatisert arbeidsflyt, noe som fører til en betydelig reduksjon i utviklingstiden.

Hvor finner du GitHub-handlinger?

GitHub-handlinger er skript som overholder et yml-dataformat. Hvert repositorium har en Handlinger-fanen som gir en rask og enkel måte å komme i gang med å konfigurere det første skriptet på. Hvis du ser en arbeidsflyt som du tror kan være et flott utgangspunkt, velger du bare Konfigurer-knappen for å legge til skriptet og begynne å redigere kildeymlen.

Skjermbilde av *Handlinger-fanen* i GitHub-handlinger som viser en enkel arbeidsflyt og en knapp for å konfigurere denne arbeidsflyten.

Men utover de GitHub-handlingene som er omtalt på Handlinger-fanen, kan du:

  • Søk etter GitHub-handlinger i GitHub Marketplace. GitHub Marketplace lar deg oppdage og kjøpe verktøy som utvider arbeidsflyten.
  • Søk etter åpne kildeprosjekter. Organisasjonen GitHub Actions har for eksempel mange populære repos for åpen kildekode som inneholder GitHub-handlinger du kan bruke.
  • Skriv dine egne GitHub-handlinger fra grunnen av. Du kan gjøre dem åpne kilder, eller til og med publisere dem til GitHub Marketplace.

Bruke GitHub-handlinger med åpen kildekode

Mange GitHub-handlinger er åpen kildekode og tilgjengelige for alle som ønsker å bruke dem. Men akkurat som med all åpen kildekode-programvare, må du sjekke dem nøye før du bruker dem i prosjektet. I likhet med anbefalte standarder for fellesskap med åpen kildekode-programvare, for eksempel en VIKTIG-fil, etiske retningslinjer, bidrande fil og problemmaler, kan du følge disse anbefalingene når du bruker GitHub-handlinger:

  • Se gjennom handlingens action.yml fil for inndata, utdata og for å sikre at koden gjør det den sier den gjør.
  • Kontroller om handlingen er i GitHub Marketplace. Denne kontrollen er verdt, selv om en handling ikke trenger å være på GitHub Marketplace for å være gyldig.
  • Kontroller om handlingen er bekreftet i GitHub Marketplace. Bekreftelse betyr at GitHub godkjente bruken av denne handlingen. Du bør imidlertid fortsatt se gjennom det før du bruker det.
  • Inkluder versjonen av handlingen du bruker, ved å angi en Git ref, SHA eller et merke.

Typer GitHub-handlinger

Det finnes tre typer GitHub-handlinger: beholderhandlinger, JavaScript-handlinger og sammensatte handlinger.

Med beholderhandlingerer miljøet en del av handlingskoden. Disse handlingene kan bare kjøres i et Linux-miljø som GitHub er vert for. Beholderhandlinger støtter mange forskjellige språk.

JavaScript-handlinger inkluderer ikke miljøet i koden. Du må angi miljøet for å utføre disse handlingene. Du kan kjøre disse handlingene i en virtuell maskin (virtuell maskin) i skyen eller lokalt. JavaScript-handlinger støtter Linux-, macOS- og Windows-miljøer.

sammensatte handlinger lar deg kombinere flere arbeidsflyttrinn i én handling. Du kan for eksempel bruke denne funksjonen til å samle sammen flere kjørekommandoer til en handling, og deretter ha en arbeidsflyt som utfører de buntede kommandoene som ett enkelt trinn ved hjelp av denne handlingen.

Anatomien til en GitHub-handling

Her er et eksempel på en handling som utfører en git-utsjekking av et repositorium. Denne handlingen, handlinger/checkout@v1, er en del av et trinn i en arbeidsflyt. Dette trinnet bygger også den Node.js koden som ble sjekket ut. Vi skal snakke om arbeidsflyter, jobber og trinn i neste del.

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

La oss si at du vil bruke en beholderhandling til å kjøre beholderkode. Handlingen kan se slik ut:

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"

Legg merke til inndelingen inputs. Her får du verdien til en variabel kalt MY_NAME. Denne variabelen er angitt i arbeidsflyten som kjører denne handlingen.

Legg merke til at du angir runs i -attributtet under uses. Når du angir denne verdien, må du angi banen til Docker-bildefilen. I dette tilfellet Dockerfile. Vi dekker ikke detaljene i Docker her, men hvis du vil ha mer informasjon, kan du se modulen Innføring i Docker Containers .

Den siste delen, branding, tilpasser handlingen i GitHub Marketplace hvis du bestemmer deg for å publisere den der.

Du finner en fullstendig liste over handlingsmetadata på metadatasyntaks for GitHub-handlinger.

Hva er en Arbeidsflyt for GitHub-handlinger?

En GitHub Actions-arbeidsflyt er en prosess som du konfigurerer i repositoriet for å automatisere livssyklusoppgaver for programvareutvikling, inkludert GitHub-handlinger. Med en arbeidsflyt kan du bygge, teste, pakke, frigi og distribuere et prosjekt på GitHub.

Hvis du vil opprette en arbeidsflyt, legger du til handlinger i en .yml fil i .github/workflows-katalogen i GitHub-repositoriet.

Arbeidsflytfilen main.yml ser slik ut i øvelsen som kommer opp:

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"

Legg merke til attributtet on: , verdien er en utløser for å angi når arbeidsflyten kjøres. Her utløser det en kjøring når det er en push-hendelse til repositoriet. Du kan angi enkelthendelser som on: push, en rekke hendelser som on: [push, pull_request]eller et hendelseskonfigurasjonskart som planlegger en arbeidsflyt eller begrenser kjøringen av en arbeidsflyt til bestemte filer, merker eller grenendringer. Kartet kan se omtrent slik ut:

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 doesn't affect the page_build event above
      - created

En hendelse utløser alle aktivitetstyper for hendelsen med mindre du angir typen eller typene. Hvis du vil ha en omfattende liste over hendelser og aktivitetstyper, kan du se: Hendelser som utløser arbeidsflyter i GitHub-dokumentasjonen.

En arbeidsflyt må ha minst én jobb. En jobb er en del av arbeidsflyten som er knyttet til en løper. En løper kan være GitHub-vert eller selvvert, og jobben kan kjøre på en maskin eller i en beholder. Du angir løperen med attributtet runs-on: . Her ber du arbeidsflyten om å kjøre denne jobben på ubuntu-latest.

Hver jobb har trinn å fullføre. I vårt eksempel bruker trinnet handlingen handlinger/checkout@v1 til å sjekke ut repositoriet. Det som er interessant er den uses: ./action-a verdien, som er banen til beholderhandlingen du bygger i en action.yml fil.

Den siste delen av denne arbeidsflytfilen angir den MY_NAME variabelverdien for denne arbeidsflyten. Husk at beholderhandlingen tok en inndata kalt MY_NAME.

Hvis du vil ha mer informasjon om arbeidsflytsyntaks, kan du se arbeidsflytsyntaks for GitHub-handlinger

Referere til handlinger i arbeidsflyter

Når du oppretter arbeidsflyter i GitHub Actions, kan du referere til handlinger fra ulike kilder. Disse handlingene kan brukes til å automatisere oppgaver i arbeidsflytene dine. Nedenfor er de primære kildene der arbeidsflyter kan referere til handlinger:

  1. En publisert Docker-beholderavbildning på Docker Hub
    Arbeidsflyter kan referere til handlinger som publiseres som Docker-beholderavbildninger på Docker Hub. Disse handlingene er beholderbaserte og inkluderer alle avhengigheter som kreves for å utføre handlingen. Hvis du vil bruke en slik handling, angir du Docker-bildet i attributtet uses for arbeidsflyttrinnet. Eksempel:

    steps:
  - name: Run a Docker action
    uses: docker://<docker-image-name>:<tag>

  2. Ethvert offentlig arkiv
    Handlinger som driftes i offentlige repositorier, kan refereres direkte til arbeidsflytene dine. Disse handlingene er tilgjengelige for alle og kan brukes ved å spesifisere repositoriumets navn og versjon (Git-ref, SHA eller tag) i attributtet uses . Eksempel:

    steps:
  - name: Use a public action
    uses: actions/checkout@v3

[! VIKTIG]

For bedre sikkerhet bør du bruke en fullstendig utfør SHA når du refererer til handlinger – ikke bare en kode som @v3.
Dette sikrer at arbeidsflyten alltid bruker nøyaktig samme kode, selv om handlingen oppdateres eller endres senere.
Eksempel: uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

  1. Samme repositorium som arbeidsflytfilen
    Du kan referere til handlinger som er lagret i samme repositorium som arbeidsflytfilen. Denne funksjonen er nyttig for egendefinerte handlinger som er spesifikke for prosjektet ditt. Hvis du vil referere til slike handlinger, bruker du en relativ bane til handlingens katalog. Eksempel:
    steps:
  - name: Use a local action
    uses: ./path-to-action

Hvis du vil ha mer informasjon, kan du se veiledning for sikkerhetsherding for GitHub Actions.

  1. En markedsplass for bedrifter
    Hvis organisasjonen bruker GitHub Enterprise, kan du referere til handlinger fra bedriftens private markedsplass. Disse handlingene kurateres og administreres av organisasjonen din, og sikrer samsvar med interne standarder. Eksempel:
    steps:
  - name: Use an enterprise marketplace action
    uses: enterprise-org/action-name@v1

Merk deg

  • Handlinger i private repositorier kan også refereres til, men de krever riktig godkjenning og tillatelser.
  • Når du refererer til handlinger, må du alltid angi en versjon (Git-ref, SHA eller tag) for å sikre konsistens og unngå uventede endringer.

Hvis du vil ha mer informasjon, kan du se Referere til handlinger i arbeidsflyter.

GitHub-vert versus selvvertede løpere

Vi nevnte kort løpere som assosiert med en jobb. En løper er ganske enkelt en server som har GitHub Actions runner-programmet installert. I det forrige eksempelet på arbeidsflyten var det et runs-on: ubuntu-latest attributt i jobbblokken, som fortalte arbeidsflyten at jobben skal kjøre ved hjelp av den GitHub-vertsbaserte løperen som kjører i ubuntu-latest miljøet.

Når det gjelder løpere, er det to alternativer å velge mellom: GitHub-vertsbaserte løpere eller selvvertede løpere. Hvis du bruker en GitHub-vert løper, kjører hver jobb i en ny forekomst av et virtuelt miljø. Den GitHub-vertsbaserte løpertypen du definerer, runs-on: {operating system-version} angir deretter dette miljøet. Med selvbetjente løpere må du bruke den selvbetjente etiketten, operativsystemet og systemarkitekturen. En selvbetjent løper med linux-operativsystem og ARM32-arkitektur vil for eksempel se ut som følgende spesifikasjon: runs-on: [self-hosted, linux, ARM32].

Hver type løper har sine fordeler, men GitHub-vertsbaserte løpere tilbyr en raskere og enklere måte å kjøre arbeidsflytene dine på, om enn med begrensede alternativer. Selvbetjente løpere er en svært konfigurerbar måte å kjøre arbeidsflyter på i ditt eget egendefinerte lokale miljø. Du kan kjøre selvbetjente løpere lokalt eller i skyen. Du kan også bruke selvlagde løpere til å opprette en egendefinert maskinvarekonfigurasjon med mer prosessorkraft eller minne. Denne typen konfigurasjon bidrar til å kjøre større jobber, installere programvare som er tilgjengelig på det lokale nettverket, og velge et operativsystem som ikke tilbys av GitHub-vertsbaserte løpere.

GitHub-handlinger kan ha bruksgrenser

GitHub Actions har noen bruksgrenser, avhengig av GitHub-planen og om løperen er GitHub-vert eller selvvert. Hvis du vil ha mer informasjon om bruksbegrensninger, kan du se Bruksgrenser, fakturering og administrasjon i GitHub-dokumentasjonen.

GitHub vert større løpere

GitHub tilbyr større løpere for arbeidsflyter som krever flere ressurser. Disse løperne er GitHub-driftede og gir økt CPU, minne og diskplass sammenlignet med standard løpere. De er utformet for å håndtere ressursintensive arbeidsflyter effektivt, noe som sikrer optimal ytelse for krevende oppgaver.

Løperstørrelser og etiketter

Større løpere er tilgjengelige i flere konfigurasjoner, noe som gir forbedret vCPI-er, RAM- og SSD-lagringsplass for å oppfylle ulike arbeidsflytkrav. Disse konfigurasjonene er ideelle for scenarioer som:

  • Kompilerer store kodebaser med omfattende kildefiler.
  • Kjører omfattende testpakker, inkludert integrering og ende-til-ende-tester.
  • Behandler store datasett for dataanalyse eller maskinlæringsoppgaver.
  • Bygge programmer med komplekse avhengigheter eller store binære utdata.
  • Utfører høyytelsessimuleringer eller beregningsmodellering.
  • Utfører videokoding, gjengivelse eller andre arbeidsflyter for multimediebehandling.

Hvis du vil bruke en større løper, angir du ønsket løperetikett i attributtet runs-on til arbeidsflytfilen. Hvis du for eksempel vil bruke en løper med 16 vCPI-er og 64 GB RAM, angir runs-on: ubuntu-latest-16coredu .

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

Disse større løperne opprettholder kompatibilitet med eksisterende arbeidsflyter ved å inkludere de samme forhåndsinstallerte verktøyene som standardløpere ubuntu-latest .

Hvis du vil ha mer informasjon om løperstørrelser for større løpere, kan du se GitHub-dokumentasjonen

Administrere større løpere

GitHub tilbyr verktøy for å administrere større løpere effektivt, noe som sikrer optimal ressursutnyttelse og kostnadsstyring. Her er noen viktige aspekter ved å administrere større løpere:

Overvåking av bruk

Du kan overvåke bruken av større løpere gjennom brukssiden for GitHub-handlinger i repositoriet eller organisasjonsinnstillingene. Denne siden gir innsikt i antall jobber som kjøres, total kjøretid og tilknyttede kostnader.

Administrere tilgang

Hvis du vil kontrollere tilgangen til større løpere, kan du konfigurere policyer på repositorium eller organisasjonsnivå. Denne konfigurasjonen sikrer at bare autoriserte arbeidsflyter eller team kan bruke disse høyressursløperne.

Kostnadsstyring

Større løpere pådrar seg ekstra kostnader basert på bruken. Hvis du vil administrere kostnader, kan du vurdere følgende forslag:

  • Bruk bare større løpere for arbeidsflyter som krever høye ressurser.
  • Reduser kjøretid ved å optimalisere arbeidsflyter.
  • Overvåk faktureringsdetaljer regelmessig for å spore utgifter.

Skalering av arbeidsflyter

Hvis arbeidsflytene krever hyppig bruk av større løpere, bør du vurdere å skalere strategier som:

  • Bruk selvadrettede løpere for forutsigbare arbeidsbelastninger.
  • Dele arbeidsflyter inn i mindre jobber for å distribuere belastningen på tvers av standardløpere.