Actions og CI/CD

fremforge kjører Forgejo Actions, et CI/CD-system som er kompatibelt med GitHub Actions. Workflow-filer bruker YAML-syntaksen fra GitHub Actions, og omtrent 95 % av actionene i GitHub Marketplace virker uten endringer.

Plassering av workflow-filer

Legg workflow-filene i .forgejo/workflows/<name>.yaml i repositoryet. Forgejo leser også .github/workflows/ av hensyn til kompatibilitet med repositoryer som er migrert fra GitHub, men .forgejo/workflows/ er den kanoniske plasseringen på fremforge.

Trigger-hendelser

Kontekstvariabler

fremforge bruker kontekstnavnene github.* for kompatibilitet med økosystemet rundt GitHub Actions. De viser til fremforge-/Forgejo-instansen, ikke til GitHub.

Innebygde secrets

Innebygde tokener er kortlivede og avgrenset til den aktuelle workflow-kjøringen. De kan ikke brukes utenfor jobben som fikk dem.

Permissions-blokken

Standardsettet med tillatelser er contents: read. Alle andre tillatelser er none som standard, med mindre de deklareres eksplisitt.

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

Deklarer tillatelser på workflow-nivå (gjelder alle jobber) eller på nivået til den enkelte jobben. Deklarasjoner på jobbnivå overstyrer dem på workflow-nivå.

Eksempel på en minimal 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

Gjenbrukbare workflower

Trekk ut felles logikk i en gjenbrukbar workflow som andre workflower kaller 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 }}"

Kall den fra en annen workflow:

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

Bufring

Bruk actions/cache for å ta vare på kataloger mellom kjøringer:

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

Treff i bufferen gjør jobbene vesentlig raskere for pakkebehandlere, byggeverktøy og kompilerte resultater. Den innebygde bufringen i actions/setup-node, setup-python, setup-go og setup-java (cache: npm osv.) bruker den samme tjenesten.

Slik oppfører bufferen seg på fremforge:

• Avgrenset til repositoryet. En buffer som er lagret i ett repository, er aldri synlig for et annet, verken i samme organisasjon eller i noen annen. Innenfor et repository deler branchene én buffer.
• Pull requests er isolert. En pull_request-kjøring kan gjenopprette bufrene til repositoryet, men det den lagrer, er bare synlig for senere kjøringer av den samme pull requesten, slik at en pull request (også en fra en fork) ikke kan endre hva andre brancher gjenoppretter.
• Grenser. Opptil 10 GiB per oppføring og 10 GiB per repository; når et repository går over, fjernes oppføringene som er brukt minst nylig. Oppføringer som ikke er brukt på 7 dager, eller som er eldre enn 30 dager, fjernes.
• Får aldri en jobb til å feile. Hvis bufferen ikke er tilgjengelig, logger actions/cache en advarsel, og jobben fortsetter uten.

Bufferen lagres på fremforges egen infrastruktur i EU.

Miljøer og sperrer for utrulling

Miljøer legger godkjenningssperrer, påkrevde godkjennere og secrets avgrenset til miljøet til utrullingsjobber.

Opprett miljøer under Organisasjonsadministrasjon → Miljøer (https://frem.sh/<org>/_admin/environments). Sett opp påkrevde godkjennere for å kreve manuell godkjenning før jobben kjører.

Referer til et miljø i en jobb:

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

Hvis production har påkrevde godkjennere, settes jobben på pause og venter på godkjenning før den kjører. Secrets som er satt på miljøet production, legges bare inn i denne jobben.

Merknader om kompatibilitet

• ~95 % av actionene i GitHub Marketplace virker uten endringer.
• secrets.GITHUB_TOKEN er et alias for secrets.FORGEJO_TOKEN. Actions som bruker det, virker som de er.
• Actions som kaller GitHub-API-et direkte (hardkodet api.github.com), vil feile. API-URL-en til fremforge er https://frem.sh/api/v1.
• Actions som leser offentlige data fra api.github.com (versjonslistene til setup-*-actionene, nedlastinger av releaser), deler GitHubs grense på 60 forespørsler per time med alle jobber på den samme utgående IP-adressen. Lås til en major.minor-versjon og send med et GitHub.com-token: se Frekvensgrensen i GitHub-API-et.
• actions/upload-artifact og actions/download-artifact virker.
• GitHub Packages (ghcr.io, pkg.github.com) er ikke tilgjengelig. Bruk heller fremforges pakkeregister.
• Actions som krever GitHub-spesifikke funksjoner (GitHub Copilot, GitHub Codespaces, GitHub Packages), har ingen motsvarighet i fremforge.
• Workflow-kommandoene ::set-output, ::set-env og ::add-path gjør ingenting. Skriv heller til $GITHUB_OUTPUT, $GITHUB_ENV og $GITHUB_PATH; se Outputs, miljøvariabler og PATH.
• Et uttrykk som ikke kan evalueres, får steget eller jobben sin til å feile, og det samme gjør en ugyldig strategy.matrix, for eksempel en exclude som nevner en verdi matrisen ikke har.
• Jobbsammendrag støttes ikke. Et steg som skriver til $GITHUB_STEP_SUMMARY, lykkes fortsatt, men sammendraget forkastes, og steg-loggen viser advarselen This Forgejo instance does not support job summaries.

Se Marketplace-kompatibilitet for hele kompatibilitetsmatrisen for de 100 mest brukte actionene.

Outputs, miljøvariabler og PATH

Siden 21. oktober 2026 har de hostede runnerne kjørt forgejo-runner 13, som fjernet tre workflow-kommandoer: ::set-output, ::set-env og ::add-path. Et steg som skriver ut en av dem, får en advarsel i loggen og fortsetter ellers, men outputen, miljøvariabelen eller PATH-oppføringen blir ikke satt. Jobben kan likevel bli grønn, og et senere steg eller en senere jobb leser da en tom verdi.

Dette betyr mest for workflower som er portert fra GitHub, der ::set-output er utfaset, men fortsatt godtas. Å sette ACTIONS_ALLOW_UNSECURE_COMMANDS=true bringer ikke kommandoene tilbake.

Skriv heller til filene runneren oppgir. Hver av dem er tilgjengelig som GITHUB_* og som FORGEJO_* og peker på den samme filen, så en workflow som også kjører på GitHub, fortsetter å virke med GITHUB_*-navnene.

Før, som nå ikke setter noe:

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

Etter:

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

Slik finner du kommandoene i et repository: git grep -nE '::(set-output|set-env|add-path)'. En Marketplace-action som fortsatt skriver dem ut, mister outputene sine på samme måte; oppdater den til en release som skriver til filene.

Rekkevidden til secrets i PR-er fra forks – policy for pull_request_target

Kort sagt: workflower som utløses av pull_request_target, kjører med målrepositoryets secrets og rettigheter, også når PR-en kommer fra en fork. Sjekk aldri ut eller kjør PR-ens head i en slik workflow (for eksempel actions/checkout med ref: ${{ github.event.pull_request.head.sha }}): da kjører kode du ikke kan stole på, ved siden av secretsene dine. Bruk pull_request til å bygge og teste bidrag; PR-er fra forks kjører der uten secrets og uten identitetstoken.

pull_request_target kjører workflower i målrepositoryets kontekst når en PR kommer fra en fork – det betyr at workflowen har tilgang til målrepositoryets secrets selv om workflow-filen kan ha blitt endret av forfatteren av forken. Dette er nøyaktig den angrepsformen som ga opphav til hendelsesklassen GitHub Actions Marketplace 2023.

fremforges policy: workflower som bruker pull_request_target, MÅ IKKE kjøre kode fra forken mens secrets er tilgjengelige. To akseptable mønstre:

1. pull_request i stedet for pull_request_target når workflowen må kjøre kode fra forken. Workflowen for fork-PR-en kjører i forkens kontekst – ingen secrets fra målrepositoryet kan nås. Dette er standard og den trygge formen.
2. pull_request_target BARE for workflower som merker, triagerer eller kommenterer med lesetilgang, som eksplisitt sjekker ut github.sha (merge-basen, ikke hodet til forken) og ikke kjører noe installasjons-, bygge- eller teststeg levert av forken.

Workflower som kombinerer pull_request_target med actions/checkout@v4 mot github.event.pull_request.head.sha, er en SEV-1-vektor for eksfiltrering av secrets og blir flagget i gjennomgangen før merge. En pre-receive-hook i Forgejo som statisk avviser den farlige kombinasjonen, står på veikartet for videre herding; til den er på plass, er kodegjennomgang den aktive sperren.

Ingen miljøer for en kjøring fra en fork (strengere enn GitHub). En pull_request_target-kjøring som utløses av en pull request fra en fork, får ikke noe miljø i det hele tatt: ingen miljø-secrets, ingen miljøvariabler og ingen environment-claim i OIDC-tokenet, selv om jobben deklarerer environment: og det er workflow-filen fra basen som kjører. GitHub gir en slik kjøring miljøet, underlagt miljøets beskyttelsesregler; fremforge gjør det ikke, siden 2026-10-27. Pull requests fra en branch i det samme repositoryet beholder miljøet sitt, lest fra workflow-filen på base-branchen og som vanlig beskyttet av miljøets branch-regel og godkjennere. Branch-regelen sjekkes mot base-branchen som pull requesten er rettet mot, som på GitHub, ikke mot pull requestens egen ref (refs/pull/<n>/head): et miljø som er begrenset til main, slipper inn en pull_request_target-jobb fra det samme repositoryet på en pull request mot main. Secrets på repository- og organisasjonsnivå er uendret: en pull_request_target-kjøring fra en fork får dem fortsatt, som på GitHub og Forgejo.

Derfor er det fortsatt farlig å sjekke ut hodet. En pull_request_target-jobb som sjekker ut og kjører koden i pull requestens hode (en installasjon, et bygg, en test, et skript fra PR-en), gir den koden alle secrets jobben fortsatt kan nå: repositoryets og organisasjonens secrets og jobbtokenet. Det endrer seg ikke av at miljøet holdes tilbake. Hold slike jobber til den lesende formen over, eller flytt arbeidet til pull_request.

Ingen OIDC-id-token for en kjøring fra en fork. En pull_request_target-kjøring som utløses av en pull request fra en fork, får ikke noe id-token: getIDToken (eller id-token: write) svarer 403, uansett audience. En slik kjøring kan derfor ikke føderere til en sky eller signere nøkkelfritt med Sigstore. En jobb som skal rulle ut eller signere, hører hjemme på push eller workflow_dispatch, etter at en vedlikeholder har merget endringen. Kjøringer fra selve repositoryet, inkludert pull requests fra en branch i det samme repositoryet, påvirkes ikke.

Mer bakgrunn: sikkerhetsmodellen i Forgejo Actions er den samme som i GitHub. Semantikken for pull_request_target er arvet, bortsett fra at fremforge ikke utsteder id-token eller miljø til en kjøring fra en fork.

Policy for image-kilder

uses:-setninger finnes i to former – begge godtas på fremforge, men utgående trafikk håndteres ulikt:

• uses: <owner>/<repo>@<sha> – slås opp mot EU-speilet for actions på frem.sh/<owner>/<repo> – hver upstream-utgiver har sin egen speilorganisasjon (actions, docker, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny, pnpm), så uses: actions/checkout@<sha> slås opp til frem.sh/actions/checkout. Speilene synkroniseres fra upstream hver 8. time. Dette er den anbefalte formen.
• uses: docker://<registry>/<image>:<tag> – Forgejo Actions løser dette ved å pulle imaget direkte fra register-URL-en som forfatteren av workflowen har oppgitt. Det skjer ingen automatisk omskriving til et fremforge-speil, og det finnes i dag ingen innebygd tillatelsesliste for registerdelen. Lås til en digest (docker://<registry>/<image>@sha256:…) i stedet for en tag som kan endres. Siden 2026-10-24 lister den daglige skanningen Låsing av workflower hver docker://-referanse som ikke er pinnet med digest. En pre-receive-hook i Forgejo eller en tillatelsesliste på runner-siden for docker:// står på veikartet for videre herding; til den er på plass, behandler du en upinnet docker://-referanse som et funn i kodegjennomgangen.

API-et for workflow-kjøringer

Det finnes fire ruter, og alle virker. Bare de to første er dokumentert noe annet sted, og derfor blir de to andre vanligvis meldt 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 ut som om avbryting ikke finnes

Alle signaler peker bort fra den, så «jeg fant den ikke» er det forventede utfallet, ikke et tegn på at du ikke har lett godt nok:

• DELETE returnerer 405. Ruten er bare POST. DELETE .../cancel og begge verbene på .../runs/<id> (uten /cancel) returnerer alle 405.
• /actions/tasks/<id>/cancel returnerer 404. Tasks er ikke kjøringer.
• Forgejos egen OpenAPI-spesifikasjon serveres ikke her. /swagger.v1.json og alle varianter av den returnerer 404 på frem.sh, så det finnes ikke noe sted å slå opp ruten.
• fremforges API-spesifikasjon beskriver den ikke, og kan ikke gjøre det. Den dokumenterer endepunktene til denne plattformen, ikke Forgejos – cancel forekommer der bare under /orgs/{org}/billing/cancel, som gjelder abonnementer. Søker du i den etter en måte å avbryte en kjøring på, finner du feil cancel.
• fremforges API svarer 501. Det er oppsamlingssvaret for /api/v1/*-stier som ikke matcher noe endepunkt, og meldingen peker mot fremforges OpenAPI-spesifikasjon – altså tilbake til spesifikasjonen som ikke inneholder denne ruten.
• ffp_*-tokener kan ikke gjøre det i det hele tatt. Den organisasjonsavgrensede proxyen formidler bare logg-ruten (se nedenfor); avbryting og ny kjøring krever et Forgejo-PAT eller en sesjonscookie.

Hvis du avbryter kjøringer for hånd mer enn én gang

Ikke skript det – sett heller en concurrency-gruppe, slik at Forgejo selv avbryter kjøringen som er blitt erstattet:

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

Hver push til en branch erstatter da sin egen forrige kjøring. Det er trygt for påkrevde sjekker: statuser gjelder per commit, så å avbryte kjøringen for en eldre commit kan ikke la sjekkene for det gjeldende hodet bli hengende.

En avbrutt kjøring får sjekkene sine til å feile. Commit-statusen for hver avbrutte jobb ender som failure med beskrivelsen Has been cancelled, enten jobben kjørte eller fortsatt ventet. Avbryter du en kjøring på commiten du prøver å merge, blir de påkrevde sjekkene røde, og en aktivert auto-merge vil ikke merge den. Push på nytt, eller bruk POST .../rerun.

Slå workflower av og på

Knappene Deaktiver workflow / Aktiver workflow på fanen Handlinger i et repository har motsvarigheter i API-et. Stiene, operasjonsnavnene og JSON-en er Giteas, så en klient skrevet for Giteas API virker uendret.

<workflow_id> er workflowens filnavn, f.eks. ci.yaml, slik det står i .forgejo/workflows/ (eller .gitea/workflows/, .github/workflows/) på standard-branchen.

# 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 innstillingen som knappene endrer, så brukergrensesnittet og API-et er alltid enige.
• name er workflowens name:, eller filnavnet når den ikke har noe. created_at og updated_at er begge tidspunktet for den siste commiten på standard-branchen, som på Gitea, ikke filens egen historikk.
• Å slå av og på krever administratorrettigheter for repositoryet, det samme som knappene. En bruker med skrivetilgang får 403. Dette er strengere enn Gitea, som lar brukere med skrivetilgang gjøre det.
• 404 for en fil som ikke er en workflow på standard-branchen. En skrivefeil, en fil på en annen branch eller en fil som ikke er .yml/.yaml i workflow-katalogen, avvises i stedet for å bli registrert.
• Et arkivert repository svarer 423 på aktivering og deaktivering. Det kan fortsatt leses.
• Begge kallene er idempotente. Å slå av en workflow som allerede er av, returnerer 204 og endrer ingenting.
• Hva «av» stopper: kjøringer fra hendelser (push, pull request og resten), planlagte kjøringer og nye kjøringer av eksisterende kjøringer (POST .../rerun svarer 422). En manuell start (POST .../actions/workflows/<workflow_id>/dispatches) kjører fortsatt, akkurat som Kjør workflow i brukergrensesnittet.
• ffp_*-tokener kan ikke kalle disse rutene. De krever et Forgejo-PAT (scope write:repository for enable/disable) eller en sesjon, som avbryting og ny kjøring.

Hente workflow-logger programmatisk

Forgejos nettgrensesnitt viser logger fra action-kjøringer interaktivt. For programmatisk tilgang (feilvarslere, feilsøkingsskript, eksport for etterlevelse, AI-agenter som triagerer feil) finnes det to endepunkter, avhengig av hvilken tokentype du har:

Med et Forgejo-PAT eller en sesjonscookie

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

Returnerer text/plain – alle jobbene i kjøringen satt sammen, med overskrifter av typen === job: <name> (status=<status>, attempt=<n>) === mellom jobbene. <run_id> er den globale ID-en Forgejo returnerer fra GET /api/v1/repos/<owner>/<repo>/actions/runs (den samme ID-en som nettgrensesnittet viser i /<owner>/<repo>/actions/runs/<n>). Tilgangskontrollen er Forgejos vanlige sjekk av lesetilgang til repositoryet; botbrukere med riktig medlemskap i organisasjonen fungerer på samme måte som menneskelige brukere.

Med et PAT for fremforges API (ffp_*)

Hvis tokenet ditt begynner med ffp_ – inkludert PAT-er som er utstedt i administrasjonsgrensesnittet, tokener mottatt fra POST /_app/api/v1/auth/token-exchange (OIDC-utveksling) og tokener utstedt av POST /_app/api/v1/oauth/token (client_credentials) – kjenner ikke Forgejo det igjen. Bruk da proxyen i fremforges API:

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

Samme svarform (text/plain, sammensatte jobber, overskrifter mellom dem). Påkrevd scope: runners:read. Proxyen kontrollerer tokenets binding til organisasjonen (<org> i URL-en må stemme med tokenets organisasjon) før forespørselen sendes videre til Forgejo med en systemlegitimasjon – systemlegitimasjonen forlater aldri plattformen, så et lekket kunde-PAT kan bare lese loggene til sin egen organisasjon.

Begge endepunktene gir samme body, så en klient som bytter autentiseringsform, trenger bare å endre URL-en og Authorization-headeren.

Merknad om midlertidig løsning. Proxyen /api/v1/orgs/<org>/repos/<repo>/... er en midlertidig bro til Forgejo upstream støtter tokener for API-domenet (ffp_*) på det innebygde endepunktet /api/v1/repos/<owner>/<repo>/.... Når det kommer, fases proxyen ut, og ffp_*-tokener vil bruke samme sti som Forgejo-PAT-er. Svarformen forblir identisk; bare formen på URL-en endres.

Når logger ikke er tilgjengelige

• 404 – kjøringen finnes ikke, eller tilhører ikke repositoryet i URL-en.
• 410 – loggene er slettet av oppryddingsjobben (action-kjøringer eldre enn oppbevaringsperioden).
• 502 – Forgejo-origin kan ikke nås. Prøv igjen; hvis det vedvarer, sjekk status.frem.sh.

Se også

• CI-runnere: tilgjengelige runner-etiketter, egne runnere, grenser for samtidighet
• Secrets: omfang for secrets, rotasjon, OIDC som alternativ
• Marketplace-kompatibilitet: kompatibilitetsmatrise for actions
• OIDC-tokenføderasjon: nøkkelfri skyutrulling fra jobber
• Pakkeregister: publisering av pakker fra CI