CI-runnere

fremforge leverer hostede runnere, som indgår i alle brugerbaserede abonnementer, og understøtter egne runnere (BYO) til teams, der har brug for on-prem, særlig hardware eller en bestemt placering i netværket. Begge typer kører Forgejo Actions-workflows med den samme GitHub Actions-YAML-syntaks.

Hostede runnere

Hostede runnere er virtuelle maskiner pr. commit på T Cloud Public i regionen eu-de (Biere/Magdeburg). En VM oprettes fra et tilpasset debian-image med Docker forudinstalleret, kører jobs fra ét commit i ét repository og slettes, når det commits jobs er færdige. Intet overlever fra et commit til det næste.

Tilgængelige labels

Henvis til et label i dit workflow:

jobs:
  build:
    runs-on: fremforge

Containerbyg fungerer på to måder fra start. Se Indholdet af runner-imaget § Containerbyg nedenfor for den fulde opdeling:

• Docker direkte på maskinen (standard): docker build, docker compose og docker pull virker bare. Docker-daemonen kører direkte på VM’en (ingen Docker-in-Docker-sidecar), så docker opfører sig som på en runner hostet af GitHub. Passer til 90 % af alle workflows.
• kaniko: uden daemon, hurtigere koldstart og bedre lag-cache mod eksterne registries. Brug det, når du ikke har brug for BuildKit-specifikke funktioner.

jobs:
  build-image:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA .
      - run: docker push registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA 2>&1 | stdbuf -oL tr '\r' '\n' | grep -vE '^(Waiting|)$'

Hostede ARM64-runnere og flere OS-varianter (Ubuntu, Fedora, …) er på køreplanen (se ændringsloggen). I dag understøtter fremforge kun x86_64 Linux. Indtil da er egne runnere (se nedenfor) vejen frem for ARM64 og workflows, der ikke kører på Linux.

Isolationsmodel

Jobs kører på dedikerede virtuelle maskiner med deres egen kerne. Platformen holder øje med Forgejo Actions-køen og starter en ny VM til et ventende job. En koldstart tager omkring 40 sekunder, før jobbets første trin kører. Der er ingen pulje af forhåndsstartede VM’er.

Ét commit, ét tillidsdomæne. En VM kører kun jobs fra det commit og det repository, den blev startet til. Når et job er færdigt, venter VM’en op til 60 sekunder på et andet job fra samme commit, i et hvilket som helst workflow, og kører det uden en ny opstart (cirka 5 sekunder til start). Derefter slukkes og slettes den. Ingen VM kører jobs fra to commits, to repositorier eller to organisationer, så betragt alle jobs fra ét commit som ét tillidsdomæne. Legitimationsoplysninger, som platformen kender til (Docker- og npm-logins og de almindelige credential-filer), nulstilles mellem jobs, men værktøjs-caches og hentede images bliver på VM’en. Se Sikkerhedsmodel for hostede runners for hele designet.

Sådan dimensionerer du jobs til hostede runnere

Hver ny VM koster omkring 40 sekunders opstart før dit første trin og ofte de 60 sekunders ventetid efter dit sidste. Et job med 15 sekunders arbejde optager derfor en VM i cirka to minutter. Så:

• Giv kun et job sin egen VM, når arbejdet tager omkring 2 minutter eller mere. Kortere tjek (lint, en lille testsuite, et guard-script) er billigere og hurtigere som ekstra trin i et eksisterende job.
• Parallelisér langt, uafhængigt arbejde (test-shards, image-byg, end-to-end-suiter) på tværs af jobs. Det er det, samtidighed er til.
• Parallelisér kort arbejde inde i ét job i stedet for på tværs af jobs, for eksempel flere tofu plan-kørsler som baggrundsprocesser i ét trin. De venter mest på API’er, ikke på CPU.
• Kæder genbruger VM’er automatisk. Et needs:-job, der bliver klar, mens forgængerens VM stadig venter (inden for 60 sekunder), kører på den VM uden opstart. En bred fan-out af jobs, der alle starter på én gang, kan ikke genbruge noget: hvert job skal have sin egen VM.
• Hold en kørsel inden for din samtidighed. En matrix, der er bredere end organisationens garanterede andel, kører i bølger, og den sidste bølge venter på, at et helt job bliver færdigt. Dimensionér shards, så en kørsel kan være i én bølge.

Hukommelse

En hostet runner-VM har 4 GiB hukommelse og ingen swap (2 vCPU). Der findes ingen større hostet runner-størrelse i dag.

Et job, der løber tør for hukommelse, fejler inden for cirka et minut. Når den ledige hukommelse falder under omkring 4 % (cirka 130 MiB), stopper runneren jobbets største proces og foretrækker byggeværktøjer som node, tsc, java og vitest-workers. Den sender først SIGTERM og SIGKILL, hvis hukommelsen bliver ved med at falde. Trinnet fejler med exitkode 143 eller 137, og trinnets log forklarer hvorfor:

earlyoom: killed node (pid 4242) because the runner VM ran out of memory. ...

Runneren selv er aldrig den proces, der stoppes, så jobbets resultat og logs bliver stadig rapporteret. Før denne ændring kunne et job, der voksede ud af VM’en, gå i stå i stilhed, indtil dets timeout-minutes udløb.

Hvis du ser denne linje, så sænk jobbets højeste hukommelsesforbrug:

• Del arbejdet op i flere jobs. Kører du et stort byg ved siden af dets integrationstests, eller en docker build ved siden af testcontainere, lægges de to toppe sammen på én VM.
• Begræns værktøjets hukommelse. For eksempel NODE_OPTIONS=--max-old-space-size=2048 til Node, --checkers 1 og GOMEMLIMIT til TypeScript 7 (tsc skrevet i Go), -Xmx til Java og færre test-workers (--maxWorkers / --pool-options).
• Stream i stedet for at indlæse. Ved scanning af store images, se Scanning af store images med Trivy.

Hvis et job ikke kan være i 4 GiB, så kontakt support@frem.sh, eller kør det på en egen runner, der er dimensioneret til det.

Inkluderede minutter og samtidighed

Jobs ud over organisationens grænse venter i køen i stedet for at fejle. Kontakt support@frem.sh, hvis du har brug for en højere garanteret andel.

Fakturering af merforbrug (frivillig): som standard sættes nye jobs i kø, når puljen er brugt op. Organisationens ejere kan slå målt merforbrug til under Administration → Fakturering → Forbrug af runner-minutter. Når det er slået til, faktureres minutter ud over puljen med 0,01 € pr. minut på næste faktura. Merforbrug kan slås fra når som helst på samme side.

Forbrugsoversigt

Følg forbruget af runner-minutter under Administration → Fakturering → Forbrug af runner-minutter.

Forbrugsoversigten viser:

Minutter tælles fra jobbets start til dets slutning, rundet op til nærmeste sekund. Køtid (ventetid på en runner) tælles ikke med.

Månedsperioden nulstilles den 1. i hver måned (UTC). Ubrugte minutter overføres ikke.

Minutter på egne runnere registreres separat i samme oversigt og trækkes ikke fra den hostede pulje.

Grænser for forbrugsadvarsler, som du selv kan justere, er ikke tilgængelige endnu. fremforge sender en standardadvarsel på mail, når organisationen når 80 % af månedens pulje. Kontakt support@frem.sh for at ændre grænsen.

Indholdet af runner-imaget

Det hostede runner-image bygges igen hver uge (mandag kl. 06:00 UTC) ud fra opstrøms værktøjsversioner, som Renovate følger. Alle downloads under bygget er låst med sha256 (bygget fejler ved afvigelse). En Trivy-CVE-gate kører under bygget: et image med fund af alvorligheden HIGH eller CRITICAL bliver ikke frigivet, før det er rettet.

Før et nybygget image tages i brug på runner-flåden, tjekkes det igen mod listerne over sårbarheder, der vides at blive udnyttet (ENISA EUVD og CISA KEV). Et image med en kendt udnyttet CVE, som der findes en rettelse til, rulles ikke ud, uanset alvorlighed, medmindre en gennemgået undtagelse på højst 30 dage dækker den CVE. Runnerne bruger det forrige image, indtil et rettet image er bygget.

Model i to lag, begge placeret i EU:

• Systemlaget (~300 MB): debian-base og systemværktøjer i én version (Node 24 LTS, build essentials, scannere, IaC- og cloud-CLI’er, browsere, databaseklienter). En del af VM’ens bootdisk; ingen download pr. job.
• hostedtoolcache-laget (~7 GB): sprogværktøjer i flere versioner (Node, Go, Python, .NET, Java, Ruby) samt Android SDK, Miniconda3 og R (siden 2026-06-06). Bagt ind i den samme bootdisk under /opt/hostedtoolcache. setup-*-actions finder dem her uden download pr. job.

Hvordan vi leverer fuld dækning på ~7 GB i alt, når GitHubs ubuntu-latest fylder ~50 GB: se størrelsessammenligningen nedenfor.

Forudinstalleret i systemlaget:

Forudinstalleret i hostedtoolcache (findes af setup-*-actions, ingen download pr. job):

Den autoritative versionsliste med de præcise versioner, image-digest, opsummering af Trivy-scanningen og CycloneDX-SBOM udgives med hvert ugentligt byg. Se referencen for runner-imaget for den aktuelle værktøjsstak.

Containerbyg: Docker direkte på maskinen eller kaniko

To veje, vælg efter arbejdsopgaven:

Docker direkte på maskinen (standard): VM’en leveres med Docker-daemonen installeret og kørende på værten. Din docker-CLI taler med den over den almindelige lokale socket, uden DOCKER_HOST-omvej og uden sidecar. Virker til docker build, docker compose, docker pull, flertrinsbyg og BuildKit-funktioner. Fuld paritet med docker på runnere hostet af GitHub.

- run: docker build -t myapp:${{ github.sha }} .
- run: docker push myapp:${{ github.sha }} 2>&1 | stdbuf -oL tr '\r' '\n' | grep -vE '^(Waiting|)$'

Scanning af store images med Trivy

trivy image <ref> (via daemonen) holder lagmetadata for hele imaget i hukommelsen, mens den gennemgår filsystemet. Images på flere GB kan derfor sende forbruget langt over runner-VM’ens hukommelsesgrænse og udløse et OOM-kill midt i scanningen. Det pålidelige mønster for images i alle størrelser er at streamme imaget via docker save:

- run: docker build -t myapp:${{ github.sha }} .
- run: |
    docker save myapp:${{ github.sha }} | trivy image \
      --severity HIGH,CRITICAL --ignore-unfixed \
      --scanners vuln --pkg-types os \
      --offline-scan --no-progress --quiet \
      --input -

Hvorfor det virker: docker save læser lagene fra disken og streamer tarballen ind i trivys stdin ét lag ad gangen. Trivy gennemgår hvert lag for OS-pakkemetadata (nogle titals KB pr. lag) og smider det væk før det næste. Det samlede maksimale RSS holder sig omkring 500 MB uanset imagets samlede størrelse, så scanningen er godt inden for runner-VM’ens hukommelsesbudget. GOGC=10 foran trivy (f.eks. GOGC=10 trivy ...) strammer heapen yderligere, hvis du nogensinde nærmer dig grænsen.

Filteret tr '\r' '\n' på docker push anbefales: Docker skriver fremdriften for lag-upload med carriage return-overskrivninger, som Forgejo Actions’ trinlog behandler som én linje, der bare vokser, og som afkortes uden varsel. Uden filteret viser en push, der går i stå eller fejler midt i uploadet, kun <layer>: Preparing i loggen uden detaljer om fejlen; når trinnet får timeout, er den egentlige fejl overskrevet. Ved at sende outputtet gennem tr bliver hvert fremdriftsskridt sin egen linje, som gemmes intakt, og grep -vE '^(Waiting|)$' fjerner tomme linjer og ventelinjer. Hastigheden for push af lag påvirkes ikke.

Dine egne registries (ghcr.io, dockerhub, quay.io eller dit eget) kan nås via runnernes udgående trafik. Proxyen har en timeout på 30 minutter pr. forespørgsel, så PUT af lag på flere GB gennemføres uden problemer. Budget for image-størrelse: 50 GB pr. byg (grænsen for VM’ens scratch-disk). Opret en sag, hvis du har brug for mere.

kaniko: OCI-bygger uden daemon og uden root. Hurtigere koldstart end den fulde Docker-daemon og bedre lag-cache mod eksterne registries. Brug den, når bygget ikke har brug for BuildKit-specifikke funktioner.

- run: |
    /usr/local/bin/kaniko \
      --context=$GITHUB_WORKSPACE \
      --dockerfile=Dockerfile \
      --destination=registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA

Til kind- og testcontainers-opgaver, der har brug for KVM-nestede gæster, tilføjer du labelet dind-privileged til runs-on. fremforge sender dem til en VM-type med nested virtualisering slået til.

Størrelse sammenlignet med GitHub-hostede runnere

GitHubs ubuntu-latest fylder ~50 GB, fordi det indeholder:

• Flere versioner pr. sprog: 3 nyere serier af Node, Python, Java og Ruby; 2 af Go og .NET (~3 GB i alt). Tabellen ovenfor er den autoritative liste.
• Android SDK + NDK (~10 GB på GitHub-hostede runnere): vi bager kerne-SDK’et ind (platform 34 + build-tools + platform-tools, ~3 GB); ekstra API-niveauer, NDK og emulatorer installeres pr. job via setup-android@v3 (uden at hente det, der allerede er bagt ind).
• Forhåndshentede Docker-images til service-containere (postgres, mysql, mongo, redis, mssql ~5 GB): ikke bagt ind. En docker pull henter dem fra Docker Hub eller gennem organisationens dependency proxy (se pakkecaches).
• Browseren Microsoft Edge: ikke bagt ind (Chromium er samme motor til headless CI-test).
• Mono / Julia / Swift / Haskell / Lua / Crystal / Nim / Elixir: ikke bagt ind (niche, installeres pr. job via setup-* eller apt).
• Flere GCC-versioner og gamle værktøjskæder, der bevares af kompatibilitetshensyn: vi leverer ét aktuelt sæt.

Vi mangler ikke de værktøjer, et typisk workflow bruger: alle almindelige sprog, alle store cloud-CLI’er, alle almindelige scannere, begge store browsere, Docker (direkte på maskinen, root via labelet dind-privileged), Android (kerne-SDK) og data science (Miniconda3 + R). iOS / Xcode virker ikke på Linux og følges separat; nichesprog (Julia/Swift/Haskell/Mono) installeres pr. job. Sig til, hvis dit team har brug for noget, vi ikke bager ind, så vurderer vi det til næste ugentlige byg af imaget.

Alle detaljer pr. værktøj finder du på docs.frem.sh/build/actions/runner-image/.

Egne runnere (BYO)

Registrér dine egne runnere i en hvilken som helst fremforge-organisation (servere on-prem, cloud-VM’er, Mac minis, Raspberry Pis). Minutter på egne runnere trækkes ikke fra den hostede pulje.

Registrering

1. Gå i organisationens Forgejo-indstillinger til Indstillinger → Handlinger → Runners → Opret ny runner (frem.sh/org/<org>/settings/actions/runners).
2. Kopiér registreringstokenet.
3. Hent Forgejo-runnerens binærfil. Den aktuelle stabile udgave udgives på code.forgejo.org/forgejo/runner/releases; lås til et nyligt tag, når du installerer:

# Linux x86_64 — replace <version> with the tag from the releases page (e.g. v6.4.0)
curl -sSL https://code.forgejo.org/forgejo/runner/releases/download/<version>/forgejo-runner-<version>-linux-amd64 \
  -o forgejo-runner && chmod +x forgejo-runner

# macOS arm64
curl -sSL https://code.forgejo.org/forgejo/runner/releases/download/<version>/forgejo-runner-<version>-darwin-arm64 \
  -o forgejo-runner && chmod +x forgejo-runner

fremforge følger de aktuelle Forgejo-udgivelser. Runnere med ældre binærfiler virker fortsat, men bør opgraderes inden for én udgivelsescyklus for at få CVE-rettelserne med.

4. Registrér runneren:

./forgejo-runner register \
  --instance https://frem.sh \
  --token <registration-token> \
  --name my-runner \
  --labels linux,self-hosted,my-custom-label

5. Start runneren:

./forgejo-runner daemon

Understøttede platforme

Egne labels

De labels, du tildeler ved registreringen, er dem, du henviser til i runs-on::

jobs:
  deploy:
    runs-on: [self-hosted, my-custom-label]

Flere labels i en liste betyder “find en runner, der har ALLE disse labels”. Labelet self-hosted er en konvention. Tag det med, så et BYO-job ikke ved et uheld sendes til en hostet runner.

Brug ikke reserverede labels. Labelene fremforge og linux/amd64 sender jobs til vores pulje af hostede runnere (de gamle aliasser fremforge-cci og cci er udfasede og sendes samme sted hen). Vælg andre labels til dine egne runnere (f.eks. self-hosted, on-prem, my-team-runner), så workflows kan pege entydigt på dem.

Netværkskrav til runnerens vært

Runnerens binærfil åbner long-poll-HTTPS-forbindelser til https://frem.sh og kloner repositorier over HTTPS. Set fra værten er kravene til forbindelse:

Der kræves ingen indgående forbindelser: runneren starter alle forbindelser udgående. En runner bag NAT eller en firewall fungerer fint, så længe den kan nå frem.sh:443.

Ansvar for sikkerhed og isolation

For hostede runnere sørger fremforge for isolation på kerneniveau mellem commits og mellem kunder (hvert commit kører i en ny, kortlivet ECS-VM; jobs fra samme commit kan dele den). For egne runnere er isolationen dit ansvar. En selvhostet runner, der håndterer workflows fra flere repositorier, deler tilstand på tværs af jobs, medmindre du begrænser hver runner til ét repository eller én organisation.

Kører du workflows fra flere teams eller tillidsdomæner, så behandl din egen runner, som man behandler selvhostede GitHub Actions-runnere:

• Én runner pr. repository (eller pr. tillidsgrænse), når secrets er følsomme.
• Registrér ikke en egen runner til et offentligt repository: alle med merge-adgang kunne lande en workflow-ændring, der kører vilkårlig kode på din runnervært.
• Behandl runnerværten som produktion: hærd OS’et, hold runnerens binærfil opdateret, og send dens udgående trafik gennem dine egne SSRF- og egress-kontroller.

fremforges udgående SSRF-proxy gælder IKKE for egne runnere, kun for hostede runnere. Din runners netværkspolitik er det, du selv sætter op på værten.

Udgående trafik og netværk

Tilladelsesliste for udgående trafik på organisationsniveau: kontakt support@frem.sh for at give runner-jobs udgående adgang til flere CIDR’er eller porte. Reglerne for udgående trafik sættes op på platformsniveau.

SSRF-proxyen er et fast minimum i platformen. Den kan ikke slås fra. Den forhindrer runner-jobs i at nå T Cloud Publics instansmetadata eller intern infrastruktur.

Secrets i jobs

Secrets indsættes som miljøvariabler og maskeres i jobloggene. Enhver loglinje, der indeholder værdien af et secret, erstattes med ***.

Syntaks for henvisning:

steps:
  - name: Deploy
    env:
      API_KEY: ${{ secrets.MY_API_KEY }}
    run: ./deploy.sh

Omfang for secrets

Miljø-secrets kræver, at jobbet angiver et miljø:

jobs:
  deploy:
    runs-on: fremforge
    environment: production
    steps:
      - run: echo ${{ secrets.PROD_API_KEY }}

Til legitimationsoplysninger hos cloududbydere bør du foretrække OIDC-tokenføderation frem for langlivede secrets. Intet secret at gemme, intet secret at rotere.

Fejlfinding

Et trin fejler med earlyoom: killed <process> ... ran out of memory.

Jobbet brugte mere end runner-VM’ens 4 GiB hukommelse, så runneren stoppede den største proces i stedet for at lade VM’en gå i stå. Se Hukommelse for, hvordan du sænker jobbets højeste forbrug.

Jobbet sidder fast i køen.

Den hyppigste årsag er, at grænsen for samtidighed pr. organisation er nået (2 samtidige jobs pr. bruger garanteret, mindst 10 og højst 60; se Inkluderede minutter og samtidighed). Se det aktuelle antal aktive jobs under Administration → Fakturering → Forbrug af runner-minutter. Er du ved grænsen, så vent på, at et kørende job bliver færdigt, eller kontakt support@frem.sh for en Enterprise-on-Demand-opgradering.

docker-kommandoen virker, men en privilegeret operation fejler (f.eks. oprettelse af en kind-klynge med KVM-nesting).

Standard-VM’en med runs-on: fremforge kører Docker direkte med rootless standardindstillinger for brugeren: docker build / docker compose / docker pull virker fra start, men operationer, der kræver ekstra rettigheder (KVM-nesting, rå adgang til /dev for en nestet gæst, visse netværkstilstande i kind-klynger), gør ikke. Tilføj labelet dind-privileged til runs-on (runs-on: [fremforge, dind-privileged]), så sender fremforge jobbet til en VM-type med nested virtualisering slået til. Samme isolation med én VM pr. commit, samme image, blot med udvidede rettigheder.

Til ren kopiering/omtagging af images mellem registries (uden byg) virker det forudinstallerede skopeo helt uden Docker-daemonen.

Et secret maskeres i loggene, men trinnet opfører sig, som om det er tomt.

Secret’et findes i runtime-miljøet (maskeringen bekræfter det), men værdien er ikke sat i det rigtige omfang. Tjek:

1. Er secret’et sat på organisationsniveau, repository-niveau eller miljøniveau?
2. Hvis det er et miljø-secret, angiver jobbet så environment: <name>, der matcher secret’ets miljø?
3. Er navnet på secret’et stavet helt korrekt (der skelnes mellem store og små bogstaver)?

Secrets-siden i det relevante omfang viser navnet på secret’et og tidspunktet for seneste opdatering. Brug den til at bekræfte, at secret’et findes, før du kigger på workflowet.

Krydshenvisninger

• OIDC-tokenføderation, nøglefri cloud-godkendelse fra CI-jobs
• Secrets, administration af organisations-, repository- og miljø-secrets
• Marketplace-kompatibilitet, hvilke GitHub Marketplace-actions der virker på fremforges runnere
• AI-holdning, hvilke AI-værktøjer der er og ikke er til stede i runner-miljøet