Actions og CI/CD

fremforge kører Forgejo Actions, et CI/CD-system, der er kompatibelt med GitHub Actions. Workflow-filer bruger GitHub Actions’ YAML-syntaks, og omkring 95 % af actions fra GitHub Marketplace virker uden ændringer.

Placering af workflow-filer

Læg workflow-filer i .forgejo/workflows/<name>.yaml i dit repository. Forgejo læser også .github/workflows/ af hensyn til repositorier, der er migreret fra GitHub, men .forgejo/workflows/ er den kanoniske placering på fremforge.

Trigger-events

Kontekstvariabler

fremforge bruger github.*-kontekstnavnene af hensyn til kompatibilitet med GitHub Actions-økosystemet. De refererer til fremforge/Forgejo-instansen, ikke til GitHub.

Indbyggede secrets

Indbyggede tokens er kortlivede og afgrænset til den aktuelle workflow-kørsel. De kan ikke bruges uden for det job, der fik dem.

Permissions-blokken

Standardrettighederne er contents: read. Alle andre rettigheder er som standard none, medmindre de erklæres eksplicit.

permissions:
  contents: read       # git checkout
  id-token: write      # OIDC token federation
  issues: write        # create / update issues
  pull-requests: write # comment on PRs

Erklær rettigheder på workflow-niveau (gælder alle jobs) eller på det enkelte job. Erklæringer på job-niveau tilsidesætter dem på workflow-niveau.

Eksempel på et minimalt workflow

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm ci && npm test

Genbrugelige workflows

Træk fælles logik ud i et genbrugeligt workflow, som andre workflows kalder med workflow_call:

# .forgejo/workflows/reusable.yaml
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string

jobs:
  deploy:
    runs-on: fremforge
    environment: ${{ inputs.environment }}
    steps:
      - run: echo "Deploying to ${{ inputs.environment }}"

Kald det fra et andet workflow:

jobs:
  deploy-staging:
    uses: ./.forgejo/workflows/reusable.yaml@main
    with:
      environment: staging

Caching

Brug actions/cache til at bevare mapper mellem kørsler:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

Cache-hits gør jobs markant hurtigere for pakkehåndteringsværktøjer, build-værktøjer og kompileret output. Den indbyggede caching i actions/setup-node, setup-python, setup-go og setup-java (cache: npm osv.) bruger den samme tjeneste.

Sådan opfører cachen sig på fremforge:

• Afgrænset til repoet. En cache, der er gemt i ét repository, er aldrig synlig for et andet, hverken i samme organisation eller i en anden. Inden for et repository deler alle branches én cache.
• Pull requests er isolerede. En pull_request-kørsel kan gendanne repoets caches, men det, den gemmer, er kun synligt for senere kørsler af samme pull request. En pull request (også fra en fork) kan derfor ikke ændre det, andre branches gendanner.
• Grænser. Op til 10 GiB pr. post og 10 GiB pr. repository; når et repository overskrider grænsen, fjernes de poster, der har været brugt mindst for nylig. Poster, der ikke er brugt i 7 dage, eller som er ældre end 30 dage, fjernes.
• Får aldrig et job til at fejle. Hvis cachen ikke er tilgængelig, logger actions/cache en advarsel, og jobbet fortsætter uden.

Cachen ligger på fremforges egen infrastruktur i EU.

Miljøer og deployment-gates

Miljøer tilføjer godkendelses-gates, påkrævede reviewere og miljøspecifikke secrets til deploy-jobs.

Opret miljøer under Administration → Miljøer (https://frem.sh/<org>/_admin/environments). Konfigurér påkrævede reviewere for at kræve manuel godkendelse, før jobbet kører.

Referér til et miljø i et job:

jobs:
  deploy-prod:
    runs-on: fremforge
    environment: production
    steps:
      - run: ./deploy.sh

Hvis production har påkrævede reviewere, venter jobbet på godkendelse, før det kører. Secrets, der er sat på miljøet production, injiceres kun i dette job.

Kompatibilitetsnoter

• Omkring 95 % af actions fra GitHub Marketplace virker uden ændringer.
• secrets.GITHUB_TOKEN er et alias for secrets.FORGEJO_TOKEN. Actions, der bruger det, virker som de er.
• Actions, der kalder GitHub API’et direkte (hardkodet api.github.com), fejler. fremforges API-URL er https://frem.sh/api/v1.
• Actions, der læser offentlige data fra api.github.com (setup-*-actions’ versionslister, downloads af releases), deler GitHubs grænse på 60 forespørgsler i timen med alle jobs på samme udgående IP-adresse. Fastgør en major.minor-version, og giv et GitHub.com-token med: se GitHubs API-ratebegrænsning.
• actions/upload-artifact og actions/download-artifact virker.
• GitHub Packages (ghcr.io, pkg.github.com) er ikke tilgængelige. Brug i stedet fremforges pakkeregister.
• Actions, der kræver GitHub-specifikke funktioner (GitHub Copilot, GitHub Codespaces, GitHub Packages), har ikke noget modstykke på fremforge.
• Workflow-kommandoerne ::set-output, ::set-env og ::add-path gør ingenting. Skriv i stedet til $GITHUB_OUTPUT, $GITHUB_ENV og $GITHUB_PATH; se Outputs, miljøvariabler og PATH.
• Et udtryk, der ikke kan evalueres, får sit step eller job til at fejle, og det samme gør en ugyldig strategy.matrix, f.eks. en exclude, der nævner en værdi, matrixen ikke har.
• Job-opsummeringer understøttes ikke. Et step, der skriver til $GITHUB_STEP_SUMMARY, lykkes stadig, men opsummeringen kasseres, og step-loggen viser advarslen This Forgejo instance does not support job summaries.

Se Marketplace-kompatibilitet for den fulde kompatibilitetsmatrix over de 100 mest brugte actions.

Outputs, miljøvariabler og PATH

Siden 21. oktober 2026 kører de hostede runners forgejo-runner 13, som har fjernet tre workflow-kommandoer: ::set-output, ::set-env og ::add-path. Et step, der udskriver en af dem, får en advarsel i sin log og fortsætter ellers, men output, miljøvariabel eller PATH-post bliver ikke sat. Jobbet kan stadig blive grønt, og et senere step eller job læser så en tom værdi.

Det betyder mest for workflows, der er flyttet fra GitHub, hvor ::set-output er udfaset, men stadig accepteres. At sætte ACTIONS_ALLOW_UNSECURE_COMMANDS=true bringer ikke kommandoerne tilbage.

Skriv i stedet til de filer, runneren angiver. Hver af dem findes både som GITHUB_* og som FORGEJO_* og peger på den samme fil, så et workflow, der også kører på GitHub, bliver ved med at virke med GITHUB_*-navnene.

Før – sætter nu ingenting:

      - id: version
        run: echo "::set-output name=tag::$(git describe --tags)"
      - run: echo "Releasing ${{ steps.version.outputs.tag }}"   # empty

Efter:

      - id: version
        run: echo "tag=$(git describe --tags)" >> "$GITHUB_OUTPUT"
      - run: echo "Releasing ${{ steps.version.outputs.tag }}"

Sådan finder du kommandoerne i et repository: git grep -nE '::(set-output|set-env|add-path)'. En Marketplace-action, der stadig udskriver dem, mister sine outputs på samme måde; opdatér den til en release, der skriver til filerne.

Secrets i pull requests fra forks – politik for pull_request_target

Kort sagt: workflows, der udløses af pull_request_target, kører med mål-repoets secrets og rettigheder, også når pull requesten kommer fra en fork. Tjek aldrig pull requestens head ud, og kør den aldrig i sådan et workflow (fx actions/checkout med ref: ${{ github.event.pull_request.head.sha }}): så kører kode, du ikke kan stole på, ved siden af dine secrets. Brug pull_request til at bygge og teste bidrag; pull requests fra forks kører dér uden secrets og uden identitetstoken.

pull_request_target kører workflows i mål-repoets kontekst, når en pull request kommer fra en fork – det vil sige, at workflowet har adgang til mål-repoets secrets, selvom workflow-filen kan være ændret af forfatteren af forken. Det er præcis det angrebsmønster, der ligger bag klassen af GitHub Actions Marketplace-hændelser fra 2023.

fremforges politik: workflows, der bruger pull_request_target, MÅ IKKE køre kode fra forken, mens secrets er til stede. To mønstre er acceptable:

1. pull_request i stedet for pull_request_target, når workflowet skal køre kode fra forken. Workflowet for pull requesten fra forken kører i forkens kontekst – mål-repoets secrets kan ikke nås. Det er standarden og den sikre form.
2. pull_request_target KUN til skrivebeskyttede workflows til labels, triage eller kommentarer, som eksplicit tjekker github.sha ud (merge-basen, ikke forkens head) og ikke kører noget install-, build- eller test-step fra forken.

Workflows, der kombinerer pull_request_target med actions/checkout@v4 mod github.event.pull_request.head.sha, er en SEV-1-vektor for udtræk af secrets og bliver markeret ved review før merge. En pre-receive-hook i Forgejo, der statisk afviser den farlige kombination, er på køreplanen for fremtidig hærdning; indtil den kommer, er code review den aktive gate.

Intet miljø for en kørsel fra en fork (strengere end GitHub). En pull_request_target-kørsel, der udløses af en pull request fra en fork, får slet intet miljø: ingen miljø-secrets, ingen miljøvariabler og intet environment-claim i sit OIDC-token, selv når jobbet erklærer environment:, og det er basens workflow-fil, der kører. GitHub giver en sådan kørsel miljøet, underlagt dets beskyttelsesregler; det gør fremforge ikke siden 27. oktober 2026. Pull requests fra en branch i samme repository beholder deres miljø, læst fra basebranchens workflow-fil og underlagt miljøets branch-regel og reviewere som normalt. Branch-reglen tjekkes mod den basebranch, som pull requesten er rettet mod, som på GitHub, ikke mod pull requestens egen ref (refs/pull/<n>/head): et miljø, der er begrænset til main, tillader et pull_request_target-job fra samme repository på en pull request mod main. Secrets på repository- og organisationsniveau er uændrede: en pull_request_target-kørsel fra en fork får dem stadig, som på GitHub og Forgejo.

Derfor er det stadig farligt at tjekke head ud. Et pull_request_target-job, der tjekker pull requestens head-kode ud og kører den (en installation, et build, en test, et script fra pull requesten), giver den kode alle de secrets, jobbet stadig kan nå: repoets og organisationens secrets samt jobbets token. At miljøet holdes tilbage, ændrer ikke på det. Hold sådanne jobs til den skrivebeskyttede form ovenfor, eller flyt arbejdet til pull_request.

Intet OIDC-id-token for en kørsel fra en fork. En pull_request_target-kørsel, der udløses af en pull request fra en fork, får intet id-token: getIDToken (eller id-token: write) svarer 403, uanset audience. En sådan kørsel kan derfor ikke føderere til en cloud eller signere nøgleløst med Sigstore. Et job, der skal udrulle eller signere, hører hjemme på push eller workflow_dispatch, efter at en maintainer har merget ændringen. Kørsler fra selve repoet, herunder pull requests fra en branch i samme repository, er ikke berørt.

Til fuld baggrund: Forgejo Actions’ sikkerhedsmodel er den samme som GitHubs. Semantikken for pull_request_target er arvet, bortset fra at fremforge hverken udsteder id-token eller miljø til en kørsel fra en fork.

Politik for image-kilder

uses:-sætninger findes i to former – begge accepteres på fremforge, men den udgående netværksprofil er forskellig:

• uses: <owner>/<repo>@<sha> – slås op i EU-action-spejlet på frem.sh/<owner>/<repo> – hver upstream-udgiver har sin egen spejl-organisation (actions, docker, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny, pnpm), så uses: actions/checkout@<sha> slås op i frem.sh/actions/checkout. Spejlene synkroniseres fra upstream hver 8. time. Det er den anbefalede form.
• uses: docker://<registry>/<image>:<tag> – Forgejo Actions slår dette op ved at hente imaget direkte fra den registry-URL, som workflowets forfatter har angivet. Der sker ingen automatisk omskrivning til et fremforge-spejl, og der er i dag ingen indbygget tilladelsesliste for registry-delen. Fastlås til et digest (docker://<registry>/<image>@sha256:…) i stedet for et foranderligt tag. Siden 24. oktober 2026 viser den daglige scanning Fastlåsning af workflows hver docker://-reference, der ikke er fastlåst med digest. En pre-receive-hook i Forgejo eller en tilladelsesliste på runner-siden for docker:// er på køreplanen for fremtidig hærdning; indtil den kommer, skal en ikke-fastlåst docker://-reference behandles som et problem i code review.

API’et til workflow-kørsler

Fire ruter findes og virker. Kun de to første er dokumenteret andre steder, hvilket er grunden til, at de to andre som regel meldes som manglende:

# stop a run that is queued or in progress
curl -X POST -H "Authorization: token <forgejo-pat>" \
  https://frem.sh/api/v1/repos/<owner>/<repo>/actions/runs/<run_id>/cancel
# -> 204, and the run's status becomes `cancelled`

Hvorfor det ser ud, som om annullering ikke findes

Alle signaler peger væk fra den, så “jeg kunne ikke finde den” er det forventede resultat og ikke et tegn på, at du har ledt dårligt:

• DELETE returnerer 405. Ruten er kun POST. DELETE .../cancel og begge verber på .../runs/<id> (uden /cancel) returnerer alle 405.
• /actions/tasks/<id>/cancel returnerer 404. Tasks er ikke kørsler.
• Forgejos egen OpenAPI-specifikation udstilles ikke her. /swagger.v1.json og alle varianter af den returnerer 404 på frem.sh, så der er intet at slå ruten op i.
• fremforges API-specifikation beskriver den ikke og kan ikke gøre det. Den dokumenterer denne platforms endpoints, ikke Forgejos – cancel optræder kun under /orgs/{org}/billing/cancel, som handler om abonnementer. Søger du i den efter en måde at annullere en kørsel på, finder du den forkerte cancel.
• fremforges API svarer 501. Det er opsamlingssvaret for /api/v1/*-stier, der ikke matcher noget endpoint, og beskeden henviser til fremforges OpenAPI-specifikation – altså tilbage til den specifikation, der ikke indeholder ruten.
• ffp_*-tokens kan slet ikke gøre det. Den organisationsafgrænsede proxy bygger kun bro til logs-ruten (se nedenfor); annullering og genkørsel kræver et Forgejo-PAT eller en sessionscookie.

Hvis du annullerer kørsler manuelt mere end én gang

Lad være med at scripte det – sæt i stedet en concurrency-gruppe, så Forgejo selv annullerer den kørsel, der er blevet overhalet:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Hver push til en branch afløser så branchens forrige kørsel. Det er sikkert for påkrævede checks: statusser gælder pr. commit, så annullering af kørslen for et ældre commit kan ikke efterlade checks på det aktuelle head hængende.

En annulleret kørsel får sine checks til at fejle. Hvert annulleret jobs commit-status ender som failure med beskrivelsen Has been cancelled, uanset om jobbet kørte eller stadig ventede. Annullerer du en kørsel på det commit, du prøver at merge, bliver dets påkrævede checks altså røde, og en aktiveret auto-merge vil ikke merge det. Push igen, eller brug POST .../rerun.

Aktivering og deaktivering af workflows

Knapperne Disable workflow / Enable workflow på et repositorys Actions-fane har API-modstykker. Stier, operationsnavne og JSON er Giteas, så en klient, der er skrevet til Giteas API, virker uændret.

<workflow_id> er workflowets filnavn, f.eks. ci.yaml, som det står i .forgejo/workflows/ (eller .gitea/workflows/, .github/workflows/) på standardbranchen.

# switch a workflow off, then back on
curl -X PUT -H "Authorization: token <forgejo-pat>" \
  https://frem.sh/api/v1/repos/<owner>/<repo>/actions/workflows/ci.yaml/disable
# -> 204
curl -X PUT -H "Authorization: token <forgejo-pat>" \
  https://frem.sh/api/v1/repos/<owner>/<repo>/actions/workflows/ci.yaml/enable
# -> 204

# which workflows are switched off?
curl -H "Authorization: token <forgejo-pat>" \
  https://frem.sh/api/v1/repos/<owner>/<repo>/actions/workflows

{
  "workflows": [
    {
      "id": "ci.yaml",
      "name": "CI",
      "path": ".forgejo/workflows/ci.yaml",
      "state": "disabled_manually",
      "created_at": "2026-10-09T08:00:00Z",
      "updated_at": "2026-10-09T08:00:00Z",
      "url": "https://frem.sh/api/v1/repos/<owner>/<repo>/actions/workflows/ci.yaml",
      "html_url": "https://frem.sh/<owner>/<repo>/src/branch/main/.forgejo/workflows/ci.yaml",
      "badge_url": "https://frem.sh/<owner>/<repo>/badges/workflows/ci.yaml/badge.svg?branch=main"
    }
  ],
  "total_count": 1
}

• state er active eller disabled_manually. Det er den samme indstilling, som knapperne ændrer, så brugerfladen og API’et er altid enige.
• name er workflowets name: eller filnavnet, hvis det ikke har noget. created_at og updated_at er begge tidspunktet for standardbranchens seneste commit, som på Gitea, ikke filens egen historik.
• Deaktivering og aktivering kræver repository-admin, ligesom knapperne. En bruger med skriveadgang får 403. Det er strengere end Gitea, som lader skrivere gøre det.
• 404 for en fil, der ikke er et workflow på standardbranchen. En tastefejl, en fil på en anden branch eller en fil, der ikke er .yml/.yaml i workflow-mappen, afvises i stedet for at blive registreret.
• Et arkiveret repository svarer 423 på aktivering og deaktivering. Det kan stadig læses.
• Begge kald er idempotente. Deaktivering af et deaktiveret workflow returnerer 204 og ændrer intet.
• Hvad “deaktiveret” stopper: kørsler fra events (push, pull request og de øvrige), planlagte kørsler og genkørsler af workflowets eksisterende kørsler (POST .../rerun svarer 422). En manuel dispatch (POST .../actions/workflows/<workflow_id>/dispatches) kører stadig, præcis som Run workflow gør i brugerfladen.
• ffp_*-tokens kan ikke kalde disse ruter. De kræver et Forgejo-PAT (scope write:repository til aktivering/deaktivering) eller en session, ligesom annullering og genkørsel.

Hent workflow-logs programmatisk

Forgejos webbrugerflade viser logs for action-kørsler interaktivt. Til programmatisk adgang (fejlnotifikationer, debug-scripts, compliance-eksporter, AI-agenter, der triagerer fejl) er der to endpoints, afhængigt af hvilken tokentype du har:

Med et Forgejo-PAT eller en sessionscookie

curl -H "Authorization: token <forgejo-pat>" \
  https://frem.sh/api/v1/repos/<owner>/<repo>/actions/runs/<run_id>/logs

Returnerer text/plain – alle kørslens jobs sat sammen, med === job: <name> (status=<status>, attempt=<n>) ===-overskrifter mellem jobbene. <run_id> er det globale id, som Forgejo returnerer fra GET /api/v1/repos/<owner>/<repo>/actions/runs (det samme id, som webbrugerfladen viser i /<owner>/<repo>/actions/runs/<n>). Adgangskontrollen er Forgejos almindelige læsetjek på repoet; bot-brugere med det rette organisationsmedlemskab fungerer på samme måde som menneskelige brugere.

Med et fremforge-API-PAT (ffp_*)

Hvis dit token starter med ffp_ – herunder PAT’er oprettet i administrationsbrugerfladen, tokens modtaget fra POST /_app/api/v1/auth/token-exchange (OIDC-udveksling) og tokens udstedt af POST /_app/api/v1/oauth/token (client_credentials) – genkender Forgejo det ikke. Brug i stedet fremforges API-proxy:

curl -H "Authorization: Bearer <ffp_…>" \
  https://frem.sh/_app/api/v1/orgs/<org>/repos/<repo>/actions/runs/<run_id>/logs

Samme svarformat (text/plain, jobs sat sammen, overskrifter imellem). Påkrævet scope: runners:read. Proxyen kontrollerer tokenets tenant-binding (<org> i URL’en skal matche tokenets tenant), før den sender videre til Forgejo med en systemlegitimation – systemlegitimationen forlader aldrig platformen, så et lækket kunde-PAT kun kan læse sin egen tenants logs.

Begge endpoints returnerer samme body, så en klient, der skifter godkendelsesform, kun skal ændre URL’en og Authorization-headeren.

Note om midlertidig løsning. Proxyen /api/v1/orgs/<org>/repos/<repo>/... er en midlertidig bro, indtil Forgejo upstream understøtter API-domænets tokens (ffp_*) på sit eget endpoint /api/v1/repos/<owner>/<repo>/.... Når det sker, udfases proxyen, og ffp_*-tokens rammer samme sti som Forgejo-PAT’er. Svarformatet forbliver identisk; kun URL’ens form ændres.

Når logs ikke er tilgængelige

• 404 – kørslen findes ikke eller tilhører ikke repoet i URL’en.
• 410 – logs er slettet af oprydningsjobbet (action-kørsler ældre end opbevaringsperioden).
• 502 – Forgejo-origin kan ikke nås. Prøv igen; hvis det fortsætter, så tjek status.frem.sh.

Krydshenvisninger

• CI-runners: tilgængelige runner-labels, egne runners, grænser for samtidighed
• Secrets: secret-scopes, rotation, OIDC som alternativ
• Marketplace-kompatibilitet: kompatibilitetsmatrix for actions
• OIDC-tokenføderation: nøgleløs udrulning til cloud fra jobs
• Pakkeregister: udgiv pakker fra CI