GitHub Actions til AI-byggede apps: test før I udgiver

Hvad er GitHub Actions?

GitHub Actions er GitHubs platform til automatiske arbejdsgange. En workflowfil beskriver, hvilken hændelse der starter arbejdet, hvilken computer det kører på, og hvilke trin der skal udføres. Filen ligger sammen med koden i.github/workflows, så ændringer i automatiseringen også får historik og kan gennemgås.

Workflow

Hele den automatiske proces i én YAML-fil.

Trigger

Hændelsen, fx et push eller en pull request.

Job

En samling trin, der kører på samme runner.

Runner

Den midlertidige computer, som udfører jobbet.

Hvorfor er et automatisk buildtjek værdifuldt?

En app kan se korrekt ud på den computer, hvor den blev bygget, og stadig fejle på en ren computer. GitHub Actions starter hver kontrol i et nyt miljø. Det afslører blandt andet manglende filer, afhængigheder, der ikke er låst, og kode, som ikke kan bygges uden lokale genveje.

• Samme kontrol hver gang: Processen afhænger ikke af, hvem der husker hvilke trin.
• Fejl før brugerne: En rød kontrol kan stoppe en dårlig ændring, før den når den stabile branch.
• Synlig dokumentation: Loggen viser præcist, hvilket trin der fejlede.
• Bedre samarbejde: En pull request viser både kodeændringen og resultatet af kontrollen.
• Grundlag for sikker udgivelse: Først når kontrollen er stabil, giver det mening at automatisere deployment.

Før I skriver workflowet

Start med et lille kontrolworkflow. Automatisk deployment og produktionsnøgler bør først tilføjes, når den grundlæggende kontrol er stabil og forstået.

1. 1. Koden skal ligge i GitHub. Følg først GitHub-guiden, hvis repositoryet ikke er på plads.
2. 2. Projektet skal kunne bygges lokalt. Kør den kommando, som skal bruges i workflowet, fx npm run build.
3. 3. En låsefil skal være committed. npm ci kræver normalt package-lock.json og installerer de aftalte versioner.
4. 4. Node-versionen skal være kendt. Brug samme understøttede version lokalt, i hostingmiljøet og i workflowet.
5. 5. Workflowet må ikke kræve produktionshemmeligheder for at bygge. Build og test bør så vidt muligt kunne køre uden adgang til rigtige kundedata eller produktionssystemer.

Opret det første workflow

Opret filen.github/workflows/check.ymli repositoryet. Eksemplet her passer til en typisk Node-baseret app med npm. Tilpas Node-versionen og kommandoerne til projektets egen package.json.

name: Kontroller app

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Hent koden
        uses: actions/checkout@v6

      - name: Klargør Node.js
        uses: actions/setup-node@v6
        with:
          node-version: '22'
          cache: npm

      - name: Installer præcise afhængigheder
        run: npm ci

      - name: Kør tests
        run: npm test --if-present

      - name: Kontroller produktionsbuild
        run: npm run build

Eksemplet bruger de aktuelle officielle hovedversioner afactions/checkoutog actions/setup-node. Kontrollér altid GitHubs dokumentation, når I opretter eller opdaterer workflowet.

Hvad gør de enkelte dele?

Sådan ser I, om kontrollen virker

1. 1. Commit og push workflowfilen til en ny branch.
2. 2. Opret en pull request mod main.
3. 3. Åbn fanen Actions eller kontrollen nederst på pull requesten.
4. 4. Åbn jobbet og læs hvert trin. En grøn markering betyder, at trinnet sluttede korrekt.
5. 5. Lav bevidst en ufarlig testfejl på branchen, og bekræft at workflowet bliver rødt.
6. 6. Ret fejlen og bekræft, at en ny kørsel bliver grøn.

Den bevidste fejl er vigtig. Ellers ved I kun, at workflowet kan blive grønt, ikke at det faktisk stopper den type fejl, I forventer.

Secrets og deployment: hold næste trin adskilt

En ren buildkontrol behøver normalt ingen hemmeligheder. Når workflowet senere skal udgive til Firebase, Netlify eller en anden platform, skal legitimationsoplysninger opbevares som GitHub Actions secrets eller helst udskiftes med kortlivede credentials gennem OpenID Connect, hvis platformen understøtter det.

• Gem aldrig tokens eller servicekontonøgler direkte i YAML-filen.
• Giv hvert credential mindst mulige rettigheder og adgang til færrest mulige ressourcer.
• Brug et beskyttet GitHub Environment til produktion, hvis udgivelsen kræver godkendelse.
• Undgå at udskrive hemmeligheder eller komplette miljøvariabler i workflowloggen.
• Gennemgå tredjeparts-actions, før I giver dem adgang til kode eller secrets.

Tjekliste: er jeres første workflow brugbart?

• □ Workflowet kører ved pull requests.
• □ Node-version og pakkehåndtering matcher projektet.
• □ Installationen bruger projektets låsefil.
• □ Relevante tests og produktionsbuildet køres.
• □ Jobbet har timeout og kun læserettighed til repositoryet.
• □ Workflowet bliver rødt ved en bevidst testfejl.
• □ Buildkontrollen kan køre uden produktionshemmeligheder og rigtige kundedata.
• □ Automatisk deployment er endnu ikke blandet ind, før kontrollen er stabil.

Hvad er næste skridt?

Når hver pull request bliver kontrolleret på samme måde, kan I tage stilling til hosting, miljøer og deployment. For mange små AI-byggede apps er Firebase et muligt samlet fundament til hosting, login og data, men opsætningen skal skelne mellem udvikling og produktion og begrænse adgang til data.