Opret en brugerdefineret GitHub-handling

Fuldført

GitHub Actions er en effektiv funktion, der hjælper dig med at gå fra kode til cloud– alt sammen fra komfort og bekvemmelighed i dit eget lager. Her får du mere at vide om de forskellige typer GitHub-handlinger og metadata, syntaks og arbejdsproceskommandoer til oprettelse af brugerdefinerede GitHub-handlinger.

Typer af GitHub-handlinger

Handlinger er individuelle opgaver, som du kan bruge til at tilpasse dine udviklingsarbejdsprocesser. Du kan oprette dine egne handlinger ved at skrive brugerdefineret kode, der interagerer med dit lager for at udføre brugerdefinerede opgaver, eller ved hjælp af handlinger, som GitHub-communityshares. Når du navigerer gennem forskellige handlinger, kan du se, at der er tre forskellige typer handlinger: handlinger Docker-objektbeholderhandlinger, JavaScript-handlingerog handlinger for sammensatte kørselstrin. Lad os se nærmere på hver handlingstype.

Handlinger for dockerobjektbeholder

Docker-objektbeholdere pakker miljøet med GitHub-handlingskoden. Det betyder, at handlingen kører i et konsistent og pålideligt miljø, fordi alle dens afhængigheder er i den pågældende objektbeholder. Hvis handlingen skal køre i en bestemt miljøkonfiguration, er Docker-objektbeholdere en god måde at gøre det på, fordi du kan tilpasse operativsystemet og værktøjerne. Ulempen er, at fordi jobbet skal bygge og hente objektbeholderen, er Docker-objektbeholderhandlinger ofte langsommere end JavaScript-handlinger.

Før du bygger en Docker-objektbeholderhandling, skal du have en grundlæggende forståelse af, hvordan du bruger miljøvariabler og Docker-objektbeholderfilsystemet. De trin, du skal udføre for at bygge en Docker-objektbeholderhandling, er derefter minimale og ligetil:

1. Opret en Dockerfile for at definere kommandoerne til at samle Docker-billedet.
2. Opret en action.yml metadatafil for at definere input og output for handlingen. Angiv den runs: using: værdi til docker og den runs: image: værdi, der skal Dockerfile i filen.
3. Opret en entrypoint.sh fil for at beskrive dockerbilledet.
4. Bekræft og send din handling til GitHub med følgende filer: action.yml, entrypoint.sh, Dockerfileog README.md.

JavaScript-handlinger

JavaScript-handlinger kan køre direkte på løbercomputeren og adskille handlingskoden fra det miljø, der bruges til at køre handlingen. Derfor forenkles handlingskoden, og den kan udføres hurtigere end handlinger i en Docker-objektbeholder.

Som en forudsætning for at oprette og bruge pakkede JavaScript-handlinger skal du downloade Node.js, som omfatter npm. Som et valgfrit trin (men et, vi anbefaler) er at bruge GitHub Actions Toolkit Node.js, som er en samling af Node.js pakker, der giver dig mulighed for hurtigt at bygge JavaScript-handlinger med mere ensartethed.

Trinnene til oprettelse af en JavaScript-handling er minimale og ligetil:

1. Opret en action.yml metadatafil for at definere input og output for handlingen, og fortæl handlingsløberen, hvordan denne JavaScript-handling skal starte.
2. Opret en index.js fil med kontekstoplysninger om Toolkit-pakker, routing og andre funktioner i handlingen.
3. Send din handling til GitHub med følgende filer: action.yml, index.js, node_modules, package.json, package-lock.jsonog README.md.

Handlinger for sammensatte kørselstrin

Handlinger for sammensatte kørselstrin giver dig mulighed for at genbruge handlinger ved hjælp af shellscripts. Du kan endda blande flere shellsprog i den samme handling. Hvis du har mange shellscripts til at automatisere flere opgaver, kan du nu nemt omdanne dem til en handling og genbruge dem til forskellige arbejdsprocesser. Nogle gange er det nemmere blot at skrive et shellscript end at bruge JavaScript eller ombryde din kode i en Docker-objektbeholder.

Pakket sammensat handling

Pakkede sammensatte handlinger bundter flere trin i en enhed, der kan genbruges. Disse handlinger er defineret i et lager og kan refereres til i arbejdsprocesser på tværs af forskellige lagre. Pakning af en sammensat handling forenkler arbejdsprocesser, reducerer duplikering og forbedrer vedligeholdelsen.

Når du opretter en pakket sammensat handling, defineres trinnene i en enkelt action.yml fil. Denne fil angiver de input, output og rækkefølgen af kommandoer eller handlinger, der skal udføres. Pakkede sammensatte handlinger er især nyttige til at automatisere gentagne opgaver eller kombinere flere shellkommandoer i en enkelt handling, der kan genbruges.

Opret en sammensat qction

1. Konfigurer en mappe til den sammensatte handling

Du skal placere den sammensatte handling i sin egen mappe i lageret.

Eksempel på mappestruktur:

.github/actions/my-composite-action/
├── action.yml
└── scripts/
    └── my-script.sh

2. Definer action.yml filen

Opret en fil i action.yml.

name: "My Composite Action"
description: "A reusable composite action that checks out code and sets up Node.js"

inputs:
  node-version:
    description: "The Node.js version to use"
    required: true

runs:
  using: "composite"
  steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.node-version }}

Seddel: Feltet Using: "composite" angiver, at denne handling er en sammensat handling.

3. Brug den sammensatte handling i en arbejdsproces

Når den sammensatte handling er oprettet, kan der refereres til den i en GitHub-handlingsarbejdsproces.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Use my composite action
        uses: ./.github/actions/my-composite-action
        with:
          node-version: '18'

Hvis din sammensatte handling deles fra et andet lager, skal du referere til den på følgende måde:

uses: owner/repository/.github/actions/my-composite-action@v1

Føj output til en sammensat handling

Sammensatte handlinger kan definere output, som arbejdsprocesser kan bruge til at overføre data mellem trin eller job. Output er især nyttige til deling af resultater eller beregnede værdier fra én handling til en anden.

I følgende eksempel vises det, hvordan du definerer og bruger et output i en sammensat handling:

Definer et output i action.yml

Filen action.yml angiver et output med navnet script-result. Dette output henter dens værdi fra outputtet result for run-script trinnet. run-script Trinnet kører en Bash-kommando for at angive outputværdien.

outputs:
  script-result:
    description: "Result from the script"
    value: ${{ steps.run-script.outputs.result }}

runs:
  using: "composite"
  steps:
    - id: run-script
      run: echo "result=Success" >> $GITHUB_OUTPUT
      shell: bash

Brug outputtet i en arbejdsproces

Når den sammensatte handling er oprettet, kan du få adgang til outputtet i en arbejdsproces. Her er et eksempel:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run composite action
        id: my-action
        uses: ./.github/actions/my-composite-action

      - name: Display result
        run: echo "Script Result: ${{ steps.my-action.outputs.script-result }}"

I dette eksempel:

• Den sammensatte handling aktiveres ved hjælp af nøgleordet uses .
• Få adgang til outputtet script-result ved hjælp af syntaksen steps.<step-id>.outputs.<output-name> .
• Vis resultatet i arbejdsproceslogfilerne.

Definer output i sammensatte handlinger for at oprette arbejdsprocesser, der kan genbruges, og modulopbyggede arbejdsprocesser. Denne fremgangsmåde forenkler datadeling og forbedrer vedligeholdelsen.

Bedste fremgangsmåder for sammensatte handlinger

Bedste praksis	Beskrivelse
Brug versionering	Brug et v1 mærke til at referere til stabil version 1.
Bevar modulære handlinger	Gruppér relaterede trin i en sammensat handling.
Dokumentinput & output	Tilføj beskrivelser af input/output i action.yml.
Test før publicering	Valider den sammensatte handling i et testlager.

Sammensat handling i en arbejdsproces

Sammensatte handlinger er en effektiv måde at forenkle arbejdsprocesser på ved at samle flere trin i en enhed, der kan genbruges. Disse handlinger giver dig mulighed for at definere en sekvens af kommandoer eller handlinger i en enkelt action.yml fil, hvilket gør det nemmere at vedligeholde og genbruge logik på tværs af arbejdsprocesser.

Fordele ved sammensatte handlinger:

• Genbrug – Definer handlinger én gang, og brug dem i flere arbejdsprocesser.
• Vedligeholdelse – Reducer duplikering ved at centralisere logik i en enkelt handling.
• Modularity – Kombiner flere shellkommandoer eller andre handlinger i en enkelt enhed.

Udvikl en handling for at konfigurere en kommandolinjegrænseflade på GitHub Actions-løbere

Mange CI/CD-arbejdsprocesser kræver en bestemt version af et CLI-værktøj for at interagere med cloudtjenester, administrere infrastruktur eller udføre scripts. Selvom GitHub-hostede løbere er forudinstalleret med mange værktøjer, indeholder de muligvis ikke den nøjagtige version, som dine arbejdsprocesbehov kræver, især hvis det er en ældre eller ikke-understøttet version. I stedet for at installere den påkrævede CLI-version i alle arbejdsprocesser kan du oprette en GitHub-handling, der kan genbruges , som:

• Sikrer ensartet installation af den påkrævede CLI-version på tværs af job.
• Forenkler arbejdsprocesser ved at centralisere installationslogikken.
• Optimerer cachelagring til hurtigere udførelse af arbejdsprocesser.

Sådan udvikler du en handling til konfiguration af kommandolinjegrænsefladen

En CLI-installationshandling er en JavaScript-baseret handling , der installerer og konfigurerer en kommandolinjegrænseflade på en GitHub-løber.

Trin til oprettelse af handlingen:

Trin 1: Konfigurer handlingsmappen

Følg disse trin for at oprette mappen til installationen af kommandolinjegrænsefladen manuelt:

1. Gå til dit lager

2. Opret en ny mappe til handlingen
   Opret en ny mappe med navnet my-cli-action i mappen .github/actions . Dette sikrer, at din handling er organiseret og følger GitHubs anbefalede struktur for brugerdefinerede handlinger.

3. Gå til den nye mappe
   Skift til den nyoprettede mappe for at begynde at tilføje filer til din handling:

4. Kontrollér mappestrukturen
   Når du har oprettet mappen, bør lagerstrukturen se sådan ud:

your-repository/
├── .github/
│   ├── actions/
│   │   ├── my-cli-action/

Du er nu klar til at fortsætte med at oprette action.yml filen og andre nødvendige filer til installationshandlingen for kommandolinjegrænsefladen.

Trin 2: Definer action.yml metadatafilen

Opret en action.yml fil for at beskrive handlingen.

name: "Setup MyCLI"
description: "Installs MyCLI and adds it to the PATH"
author: "Your Name"

inputs:
  version:
    description: "The CLI version to install"
    required: false
    default: "latest"

runs:
  using: "node16"
  main: "index.js"

Hvorfor bruge : node16? Denne handling kører JavaScript-kode ved hjælp af Node.js 16.

Trin 3: Opret et JavaScript-script for at installere kommandolinjegrænsefladen

Opret en fil med navnet index.js i den samme mappe, og tilføj følgende kode:

const core = require('@actions/core');
const { execSync } = require('child_process');

async function run() {
  try {
    const version = core.getInput('version') || 'latest';
    
    console.log(`Installing MyCLI version: ${version}...`);

    execSync(`curl -fsSL https://cli.example.com/install.sh | sh`, { stdio: 'inherit' });

    console.log("MyCLI installed successfully.");
  } catch (error) {
    core.setFailed(`Installation failed: ${error.message}`);
  }
}

run();

JavaScript-koden ovenfor bruger core.getInput() til at hente den CLI-version, der er angivet som input. Derefter udføres en krøllekommando for at downloade og installere kommandolinjegrænsefladen. Hvis installationsprocessen mislykkes, bruger handlingen core.setFailed() til at markere arbejdsprocessen som mislykket.

Trin 4: Test handlingen lokalt

Før du bruger handlingen i en arbejdsproces, skal du teste den på en GitHub-hostet løber.
Opret en arbejdsprocesfil (.github/arbejdsprocesser/test.yml) i dit lager:

name: Test MyCLI Setup

on:
  push:
    branches:
      - main
      - feature/*

1. Udløser arbejdsprocessen
Arbejdsprocessen udløses ved push til hovedgrenen og en hvilken som helst forgrening, der matcher funktionen/* mønsteret. Du kan justere dette, så det passer til dit lagers forgreningsstrategi.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

2. Klon lageret
Handlingen actions/checkout@v4 bruges til at klone lageret til løberen. Dette sikrer, at arbejdsprocessen har adgang til lagerets filer.

      - name: Install MyCLI
        uses: ./.github/actions/my-cli-action
        with:
          version: '1.2.3'

3. Kør den brugerdefinerede handling
Anvendelserne: ./.github/actions/my-cli-action line refererer til den brugerdefinerede handling lokalt. Kontrollér, at handlingsmappen og action.yml filen er konfigureret korrekt. Versionsinput angiver den CLI-version, der skal installeres – i dette tilfælde version 1.2.3.

      - name: Verify CLI Installation
        run: |
          echo "Checking MyCLI version..."
          mycli --version

4. Kontrollér installationen af kommandolinjegrænsefladen
Dette trin kører en shellkommando for at kontrollere, at kommandolinjegrænsefladen blev installeret. Den kontrollerer versionen af den installerede kommandolinjegrænseflade ved at køre mycli --version.

Test lokalt

Hvis du vil teste denne arbejdsproces lokalt, skal du bruge act CLI-værktøjet:

act -j test

Dette simulerer gitHub-handlingsmiljøet på din lokale computer, så du kan foretage fejlfinding og validere arbejdsprocessen, før du pusher ændringer.

Optimeringstip: Cachelagring

Hvis du vil forbedre ydeevnen for arbejdsprocessen, skal du cachelagre CLI-installationsmappen ved hjælp af handlingen actions/cache :

      - name: Cache MyCLI
        uses: actions/cache@v4
        with:
          path: ~/.mycli
          key: mycli-${{ runner.os }}-${{ inputs.version }}

Dette sikrer, at efterfølgende kørsler genbruger den cachelagrede CLI-installation, hvilket reducerer installationstiden.

Bedste fremgangsmåder for handlinger til konfiguration af kommandolinjegrænsefladen

Bedste praksis	Beskrivelse
Brug versionering	Tillad brugere at angive en CLI-version via inputs.version.
Håndter fejl korrekt	Bruges core.setFailed() til at afslutte ved fejl.
Cacheinstallation af kommandolinjegrænseflade	Optimer ydeevnen for arbejdsprocessen ved hjælp af actions/cache.
Angiv dokumentation	Forklar forbrug og input i README.md.

Foretag fejlfinding af JavaScript-handlinger

Når du arbejder med JavaScript-baserede GitHub-handlinger, kan der opstå uventede funktionsmåder, fejl eller fejl under udførelse af arbejdsprocessen. Dette undermodul indeholder teknikker og værktøjer, der kan hjælpe dig med at identificere og løse problemer i dine JavaScript-handlinger.

Almindelige fejlfindingsscenarier

Problem	Mulig årsag	Foreslået rettelse
Handlingen mislykkes med en staksporing	Syntaks- eller kørselsfejl i index.js	Brug console.log() og kontrollér logge
Input er undefined	Forkert inputnavn eller manglende input	Bekræft action.yml , og hvordan input overføres
Miljøvariabler er ikke angivet	core.exportVariable eller process.env ikke bruges korrekt	Gennemse den kode, der angiver variablerne
Filen blev ikke fundet	Manglende relative stier	Brug __dirname eller komplette stier til filer
Cachen er ikke gendannet	Forkert key eller path værdier	Kontrollér cachekonfiguration og -nøgler

Brug logføring til fejlfinding

Logfør meddelelser med core.info, core.debugog console.log

const core = require('@actions/core');

core.info("This is an info message");
core.debug("This is a debug message");
console.log("This is a raw console log");

✅ Brug core.debug til fejlfindingslogge – disse vises kun, når ACTIONS_STEP_DEBUG er angivet til true.

Aktivér logføring af fejlfinding

Du kan aktivere fejlfindingslogge på trinniveau ved at angive følgende hemmelighed:

ACTIONS_STEP_DEBUG=true

Hvis du vil aktivere diagnosticeringslogge for løbere, skal du angive:

ACTIONS_RUNNER_DEBUG=true

Angiv hemmeligheder til fejlfinding

1. Gå til dit GitHub-lager.
2. Gå til Indstillinger>Hemmeligheder og variabler>Handlinger.
3. Tilføj nye hemmeligheder med følgende navne og værdier:
   • ACTIONS_STEP_DEBUG: true
   • ACTIONS_RUNNER_DEBUG: true

Undersøg arbejdsproceslogge

Når en arbejdsproces mislykkes, skal du klikke på det mislykkede job under fanen Handlinger. Udvid hvert trin til:

• Få vist detaljerede logge
• Kontrollér standardoutput (stdout)
• Se afslutningskoden for scripts
• Identificer ubehandlede undtagelser

🔍 Eksempel på logoutput

Error: Cannot find module '@actions/core'
Require stack:
- /home/runner/work/_actions/my-org/my-action/index.js

✅ Rettelse: Kør npm-installation @actions/core , og bekræft node_modules (eller brug ncc til at bundte handlingen).

Test din handling lokalt

Brug handling – et CLI-værktøj til at køre GitHub-handlinger lokalt. Eksempel:

act -j test

🛠 Sørg for at simulere dit GitHub-miljø korrekt, når du tester lokalt.

Håndter fejl på en elegant måde

Fange undtagelser og mislykkes med nyttige meddelelser:

try {
  // your logic
} catch (error) {
  core.setFailed(`Action failed with error: ${error.message}`);
}

🔁 Dette sikrer, at GitHub stopper arbejdsprocessen ved fejl og leverer læsbare logge.

Bedste fremgangsmåder til fejlfinding af JavaScript-handlinger

Praksis	Beskrivelse
Brug core.debug()	Skjul detaljerede logge, medmindre fejlfinding er aktiveret.
Valider action.yml	Sørg for, at input og output er korrekt defineret.
Pakkekode	Bruges @vercel/ncc til at kompilere JavaScript til en enkelt fil. Dette reducerer afhængigheder og sikrer, at alle påkrævede moduler er inkluderet, hvilket forhindrer kørselsfejl, der skyldes manglende filer.
Test med handling	Simuler kørsler lokalt for at få hurtigere gentagelser.
Brug try/catch	Undgå, at arbejdsprocesser mislykkes uovervåget.

Foretag fejlfinding af handlinger i Docker-objektbeholdere

Docker-objektbeholderhandlinger er effektive til indkapsling af komplekse værktøjer og miljøer i GitHub Actions-arbejdsprocesser. Fejlfinding af disse handlinger kan dog være mere udfordrende end JavaScript-handlinger på grund af deres isolerede kørselsmiljø. Dette undermodul hjælper dig med at identificere, diagnosticere og løse problemer med Docker-baserede handlinger.

Almindelige problemer i Docker-objektbeholderhandlinger

Problem	Årsag	Foreslået rettelse
Handlingen kan ikke startes	ENTRYPOINT eller CMD forkert konfigureret	Bekræft, at Dockerfile bruger ENTRYPOINT korrekt
Manglende afhængigheder	Afhængigheder, der ikke er installeret eller konfigureret forkert	Sørg for, at alle pakker er installeret på billedet
Input blev ikke modtaget	INPUT_ der ikke er adgang til miljøvariabler	Brug process.env.INPUT_<INPUT_NAME> (eller shell tilsvarende)
Filen blev ikke fundet	Forkert filsti i objektbeholder	Brug absolutte stier, eller valider mappestrukturen
Tilladelse nægtet	Filen eller scriptet mangler udførelsestilladelse	Tilføj RUN chmod +x <script> i Dockerfile
Netværksrelaterede fejl	Eksterne tjenester er ikke tilgængelige	Valider netværksindstillinger, og prøv logik igen

Forstå Docker-handlingslivscyklussen

Før du foretager fejlfinding, er det nyttigt at forstå, hvordan Handlinger for Docker-objektbeholdere kører.

1. Arbejdsprocesudløser

En Arbejdsproces for GitHub-handlinger starter som svar på en konfigureret hændelse, f.eks. en push, pull_requesteller manuel workflow_dispatch.

2. Opstilling af løber

GitHub klargør en ny virtuel maskine ( løberen) til udførelse af arbejdsprocessen. Løberen forbereder miljøet ved at downloade handlingsdefinitioner og løse afhængigheder.

3. Handlingsløsning

Hvis handlingen angiver runs.using: docker i filen action.yml , genkender GitHub den som en Docker-baseret handling.

4. Billedbuild eller Pull

GitHub bygger det Docker-billede, der er defineret i handlingens Dockerfile , eller henter et færdigbygget billede, hvis det er angivet. Dette billede definerer det miljø, som handlingskoden kører i.

5. Kørsel af objektbeholder

Løberen starter Docker-objektbeholderen, monterer arbejdsområdet og indsætter miljøvariabler, herunder hemmeligheder og input, der er defineret i arbejdsprocessen.

6. Kørsler af indgangspunkt

GitHub udfører kommandoen entrypoint fra Dockerfile i objektbeholderen. Det er her, den brugerdefinerede handlingslogik kører, typisk et script eller et program.

7. Resultathåndtering

Alle output, der er angivet af objektbeholderhandlingen, registreres af løberen og overføres til efterfølgende trin i arbejdsprocessen. Når den er fuldført, lukkes objektbeholderen, og løberen kasseres.

Bemærk! Docker-objektbeholderhandlinger kører i et rent, isoleret miljø. Filsystemtilstand, installerede værktøjer og miljøvariabler skal alle være defineret i Dockerfile.

Fejlfindingsteknikker

1. Tilføj logføring

Brug ekko-, udskrifts- eller logføringssætninger i dit entrypoint-script:

echo "Starting Docker action..."
echo "Input VALUE: $INPUT_VALUE"

Logfør alle kritiske input og trin for at diagnosticere, hvor fejlen opstår.

2. Byg og test lokalt

Brug Docker på computeren til at simulere funktionsmåden for objektbeholderen:

docker build -t my-action .
docker run -e INPUT_NAME=value my-action

Sørg for, at miljøvariabler efterligner dem, der er i GitHub-sæt.

3. Brug handlingen CLI til at simulere GitHub-arbejdsprocesser

Installér handling for at køre dine GitHub-arbejdsprocesser lokalt:

act -j test-job

Fantastisk til test af Docker-handlinger i arbejdsprocesser uden at skulle sende til GitHub.

4. Valider konfigurationen af Dockerfile

Sørg for at definere enten ENTRYPOINT eller CMD. Kopiér dine scripts til billedet, og giv dem tilladelse til at udføre:

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

5. Undersøg GitHub-logge

Klik på en mislykket kørsel af arbejdsprocessen, udvid hvert trin, og undersøg:

• Docker-buildlogge
• Standardoutput og standardfejl fra objektbeholderen
• Afslutningskoder og staksporingslogge 🔍 afslører ofte manglende pakker, syntaksproblemer eller tilladelsesfejl.

Eksempel: Fejl i indgangspunkt

Error: container_linux.go:380: starting container process caused "exec: \"/entrypoint.sh\": permission denied"

✅ Rettelse: Tilføj RUN chmod +x /entrypoint.sh i din Dockerfile.

Tilknytning af miljøvariabel

GitHub-input	Docker-miljøvariabel
with: name: test	INPUT_NAME=test
GITHUB_WORKSPACE	Tilknyttet /github/workspace
GITHUB_EVENT_NAME	Hændelse, der udløste arbejdsprocessen

echo "Input was $INPUT_NAME"
echo "Working dir: $GITHUB_WORKSPACE"

Brug fejlfindingshemmeligheder

Aktivér yderligere logføring ved at føje disse hemmeligheder til dit lager eller din organisation:

Hemmelig	Beskrivelse
ACTIONS_STEP_DEBUG	Aktiverer logføring af fejlfinding
ACTIONS_RUNNER_DEBUG	Aktiverer løberdiagnosticering

Bedste praksis for fejlfinding af Docker-handlinger

Bedste praksis	Hvorfor
Brug logføring generøst	Hjælper med at spore fejlpunkter
Angiv altid chmod +x	Undgå tilladelsesfejl i shellscripts
Valider input i dit script	Fang manglende eller forkert udformede input tidligt
Minimer objektbeholderafhængigheder	Mindre billeder er nemmere at foretage fejlfinding af
Test lokalt med dockerkørsel eller handling	Hurtigere gentagelser og øjeblikkelig feedback