Actions och CI/CD

fremforge kör Forgejo Actions, ett CI/CD-system som är kompatibelt med GitHub Actions. Arbetsflödesfilerna använder samma YAML-syntax som GitHub Actions, och ungefär 95 % av actions från GitHub Marketplace fungerar utan ändringar.

Var arbetsflödesfilerna ligger

Lägg arbetsflödesfilerna i .forgejo/workflows/<name>.yaml i ditt repo. Forgejo läser också .github/workflows/ för kompatibilitet med repon som migrerats från GitHub, men .forgejo/workflows/ är den kanoniska platsen på fremforge.

Utlösande händelser

Kontextvariabler

fremforge använder kontextnamnen github.* för kompatibilitet med GitHub Actions-ekosystemet. De syftar på fremforge/Forgejo-instansen, inte på GitHub.

Inbyggda secrets

Inbyggda tokens är kortlivade och avgränsade till den aktuella körningen av arbetsflödet. De kan inte användas utanför det jobb som tog emot dem.

Permissions-blocket

Standarduppsättningen behörigheter är contents: read. Alla andra behörigheter är none som standard om de inte deklareras uttryckligen.

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

Deklarera behörigheter på arbetsflödesnivå (gäller alla jobb) eller på nivån för enskilda jobb. Deklarationer på jobbnivå går före dem på arbetsflödesnivå.

Minimalt exempel på ett arbetsflöde

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

Återanvändbara arbetsflöden

Bryt ut gemensam logik till ett återanvändbart arbetsflöde som andra arbetsflöden anropar 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 }}"

Anropa det från ett annat arbetsflöde:

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

Cache

Använd actions/cache för att behålla kataloger mellan körningar:

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

Cacheträffar gör jobben betydligt snabbare för pakethanterare, byggverktyg och kompilerade resultat. Den inbyggda cachningen i actions/setup-node, setup-python, setup-go och setup-java (cache: npm och så vidare) använder samma tjänst.

Så beter sig cachen på fremforge:

• Avgränsad till repot. En cache som sparats i ett repo syns aldrig i ett annat, varken i samma organisation eller i någon annan. Inom ett repo delar alla branches en cache.
• Pull requests är isolerade. En pull_request-körning kan återställa repots cacher, men det den sparar syns bara för senare körningar av samma pull request. En pull request (även en från en fork) kan alltså inte ändra vad andra branches återställer.
• Gränser. Högst 10 GiB per post och 10 GiB per repo; när ett repo går över gränsen tas de poster bort som använts minst nyligen. Poster som inte använts på 7 dagar, eller som är äldre än 30 dagar, tas bort.
• Får aldrig ett jobb att misslyckas. Om cachen inte är tillgänglig loggar actions/cache en varning och jobbet fortsätter utan den.

Cachen lagras på fremforges egen infrastruktur i EU.

Miljöer och spärrar för driftsättning

Miljöer lägger till godkännandesteg, obligatoriska granskare och miljöavgränsade secrets för driftsättningsjobb.

Skapa miljöer under Organisationens administration → Miljöer (https://frem.sh/<org>/_admin/environments). Konfigurera obligatoriska granskare för att kräva ett manuellt godkännande innan jobbet körs.

Referera till en miljö i ett jobb:

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

Om production har obligatoriska granskare konfigurerade pausas jobbet tills det godkänts. Secrets som är satta på miljön production skickas bara in i det här jobbet.

Kompatibilitet

• Cirka 95 % av actions från GitHub Marketplace fungerar utan ändringar.
• secrets.GITHUB_TOKEN är ett alias för secrets.FORGEJO_TOKEN. Actions som använder det fungerar som de är.
• Actions som anropar GitHubs API direkt (hårdkodat api.github.com) misslyckas. fremforges API-URL är https://frem.sh/api/v1.
• Actions som läser offentliga data från api.github.com (setup-*-actions versionslistor, nedladdningar av releaser) delar GitHubs gräns på 60 förfrågningar per timme med alla jobb på samma utgående IP-adress. Lås en major.minor-version och skicka med en GitHub.com-token: se GitHubs API-gräns.
• actions/upload-artifact och actions/download-artifact fungerar.
• GitHub Packages (ghcr.io, pkg.github.com) är inte tillgängligt. Använd i stället fremforges paketregister.
• Actions som kräver GitHub-specifika funktioner (GitHub Copilot, GitHub Codespaces, GitHub Packages) har ingen motsvarighet i fremforge.
• Arbetsflödeskommandona ::set-output, ::set-env och ::add-path gör ingenting. Skriv i stället till $GITHUB_OUTPUT, $GITHUB_ENV och $GITHUB_PATH; se Utdata, miljövariabler och PATH.
• Ett uttryck som inte kan utvärderas får sitt steg eller jobb att misslyckas, och detsamma gäller en ogiltig strategy.matrix, till exempel en exclude som anger ett värde som matrisen inte har.
• Jobbsammanfattningar stöds inte. Ett steg som skriver till $GITHUB_STEP_SUMMARY lyckas ändå, men sammanfattningen kastas och stegets logg visar varningen This Forgejo instance does not support job summaries.

Se Marketplace-kompatibilitet för den fullständiga kompatibilitetsmatrisen för de 100 vanligaste actions.

Utdata, miljövariabler och PATH

Sedan den 21 oktober 2026 kör de hostade runnerna forgejo-runner 13, som har tagit bort tre arbetsflödeskommandon: ::set-output, ::set-env och ::add-path. Ett steg som skriver ut något av dem får en varning i sin logg och fortsätter i övrigt, men utdatat, miljövariabeln eller posten i PATH sätts inte. Jobbet kan ändå bli grönt, och ett senare steg eller jobb läser då ett tomt värde.

Det här spelar störst roll för arbetsflöden som porterats från GitHub, där ::set-output är föråldrat men fortfarande accepteras. Att sätta ACTIONS_ALLOW_UNSECURE_COMMANDS=true tar inte tillbaka kommandona.

Skriv i stället till filerna som runnern anger. Var och en finns både som GITHUB_* och som FORGEJO_* och pekar på samma fil, så ett arbetsflöde som också körs på GitHub fortsätter att fungera med namnen GITHUB_*.

Före, vilket nu inte sätter något:

      - 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å hittar du kommandona i ett repo: git grep -nE '::(set-output|set-env|add-path)'. En Marketplace-action som fortfarande skriver ut dem förlorar sina utdata på samma sätt; uppdatera den till en release som skriver till filerna.

Fork-PR:ers åtkomst till secrets — policy för pull_request_target

Kort sagt: arbetsflöden som startas av pull_request_target körs med mål-repots secrets och behörigheter, även när PR:en kommer från en fork. Checka aldrig ut och kör aldrig PR:ens head i ett sådant arbetsflöde (till exempel actions/checkout med ref: ${{ github.event.pull_request.head.sha }}): då körs kod du inte kan lita på bredvid dina secrets. Använd pull_request för att bygga och testa bidrag; PR:er från forkar körs där utan secrets och utan identitetstoken.

pull_request_target kör arbetsflöden i mål-repots kontext när en PR kommer från en fork. Arbetsflödet har alltså åtkomst till mål-repots secrets, trots att arbetsflödesfilen kan ha ändrats av forkens författare. Det är exakt det attackmönster som låg bakom incidentklassen GitHub Actions Marketplace 2023.

fremforges policy: arbetsflöden som använder pull_request_target FÅR INTE köra kod från forken medan secrets finns tillgängliga. Två godtagbara mönster:

1. pull_request i stället för pull_request_target när arbetsflödet behöver köra kod från forken. Fork-PR:ens arbetsflöde körs i forkens kontext, och inga secrets från mål-repot kan nås. Det är standard och det säkra mönstret.
2. pull_request_target ENDAST för skrivskyddade arbetsflöden för etikettering, triage eller kommentarer som uttryckligen checkar ut github.sha (merge-basen, inte forkens head) och inte kör något install-, bygg- eller teststeg från forken.

Arbetsflöden som kombinerar pull_request_target med actions/checkout@v4 mot github.event.pull_request.head.sha är en SEV-1-väg för att läcka secrets och flaggas vid granskningen före merge. En pre-receive-hook i Forgejo som statiskt avvisar den farliga kombinationen finns på färdplanen för framtida härdning; tills den finns är kodgranskningen den aktiva spärren.

Ingen miljö för en körning från en fork (striktare än GitHub). En pull_request_target-körning som startas av en pull request från en fork får ingen miljö alls: inga miljösecrets, inga miljövariabler och inget environment-claim i sin OIDC-token, även när jobbet deklarerar environment: och det är basens arbetsflödesfil som körs. GitHub ger en sådan körning miljön, med förbehåll för miljöns skyddsregler; fremforge gör det inte sedan 2026-10-27. Pull requests från en branch i samma repo behåller sin miljö, som läses från bas-branchens arbetsflödesfil och spärras av miljöns branch-regel och granskare som vanligt. Branch-regeln kontrolleras mot den bas-branch som pull requesten riktar sig mot, precis som på GitHub, inte mot pull requestens egen ref (refs/pull/<n>/head): en miljö som är begränsad till main släpper in ett pull_request_target-jobb från samma repo på en pull request mot main. Secrets för repo och organisation påverkas inte: en forks pull_request_target-körning får dem fortfarande, precis som på GitHub och Forgejo.

Därför är det fortfarande farligt att checka ut head. Ett pull_request_target-jobb som checkar ut och kör pull requestens head-kod (en installation, ett bygge, ett test, ett skript från PR:en) ger den koden alla secrets som jobbet fortfarande når: repots och organisationens secrets och jobbets token. Att miljön hålls inne ändrar inte det. Håll sådana jobb till det skrivskyddade mönstret ovan, eller flytta arbetet till pull_request.

Ingen OIDC-id-token för en körning från en fork. En pull_request_target-körning som startas av en pull request från en fork får ingen id-token: getIDToken (eller id-token: write) svarar 403, oavsett audience. En sådan körning kan alltså inte federera till ett moln eller signera nyckellöst med Sigstore. Ett jobb som behöver driftsätta eller signera hör hemma på push eller workflow_dispatch, efter att en maintainer har mergat ändringen. Körningar från repot självt, även pull requests från en branch i samma repo, påverkas inte.

Fullständig bakgrund: säkerhetsmodellen för Forgejo Actions är densamma som GitHubs. Semantiken för pull_request_target är ärvd, förutom att fremforge varken ger id-token eller miljö till en forks körning.

Policy för image-källor

uses:-satser finns i två former. Båda accepteras på fremforge, men vägen ut på nätet skiljer sig:

• uses: <owner>/<repo>@<sha> — slås upp mot EU-spegeln för actions på frem.sh/<owner>/<repo>. Varje uppströms utgivare har en egen spegelorganisation (actions, docker, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny, pnpm), så uses: actions/checkout@<sha> slås upp till frem.sh/actions/checkout. Speglarna synkas från uppströms var 8:e timme. Det här är den rekommenderade formen.
• uses: docker://<registry>/<image>:<tag> — Forgejo Actions hämtar då imagen direkt från den registry-URL som arbetsflödets författare angav. Det finns ingen automatisk omskrivning till en fremforge-spegel, och i dag ingen inbyggd tillåtelselista för registry-delen. Fäst vid en digest (docker://<registry>/<image>@sha256:…) i stället för en föränderlig tagg. Sedan 2026-10-24 listar den dagliga skanningen Fästning av arbetsflöden varje docker://-referens som inte är fäst vid en digest. En pre-receive-hook i Forgejo eller en tillåtelselista på runnersidan för docker:// finns på färdplanen för framtida härdning; tills den finns ska du behandla en ofäst docker://-referens som en fråga för kodgranskningen.

API:t för arbetsflödeskörningar

Fyra routes finns och fungerar. Bara de två första är dokumenterade någon annanstans, och därför rapporteras de två andra oftast som saknade:

# 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`

Varför det ser ut som att avbryt inte finns

Alla signaler pekar bort från den, så “jag hittade den inte” är det väntade utfallet snarare än ett misslyckat sökande:

• DELETE returnerar 405. Routen är bara POST. DELETE .../cancel och båda verben på .../runs/<id> (utan /cancel) returnerar alla 405.
• /actions/tasks/<id>/cancel returnerar 404. Tasks är inte körningar.
• Forgejos egen OpenAPI-specifikation serveras inte här. /swagger.v1.json och alla varianter av den returnerar 404 på frem.sh, så det finns inget att slå upp routen i.
• fremforges API-specifikation beskriver den inte, och kan inte göra det. Den dokumenterar plattformens egna endpoints, inte Forgejos — cancel förekommer bara under /orgs/{org}/billing/cancel, som gäller abonnemang. Söker du i den efter ett sätt att avbryta en körning hittar du fel cancel.
• fremforges API svarar 501. Det är fångst-allt-svaret för /api/v1/*-sökvägar som inte matchar någon endpoint, och meddelandet hänvisar till fremforges OpenAPI-specifikation, alltså tillbaka till specifikationen som inte innehåller routen.
• ffp_*-tokens kan inte göra det alls. Den organisationsavgränsade proxyn överbryggar bara logg-routen (se nedan); avbryt och kör om kräver en Forgejo-PAT eller en sessionscookie.

Om du avbryter körningar för hand mer än en gång

Skripta det inte — sätt i stället en concurrency-grupp, så att Forgejo själv avbryter den ersatta körningen:

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

Varje push till en branch ersätter då dess egen föregående körning. Det är säkert för obligatoriska kontroller: statusar gäller per commit, så att avbryta körningen för en äldre commit kan inte lämna kontrollerna för nuvarande head hängande.

En avbruten körning får sina kontroller att misslyckas. Varje avbrutet jobbs commitstatus slutar som failure med beskrivningen Has been cancelled, oavsett om jobbet kördes eller fortfarande väntade. Avbryter du en körning på den commit du försöker merga blir alltså dess obligatoriska kontroller röda, och en aktiverad auto-merge mergar den inte. Pusha, eller POST .../rerun.

Slå på och stänga av arbetsflöden

Knapparna Disable workflow / Enable workflow på ett repos flik Actions har motsvarigheter i API:t. Sökvägarna, operationsnamnen och JSON är Giteas, så en klient som skrivits för Giteas API fungerar utan ändringar.

<workflow_id> är arbetsflödets filnamn, t.ex. ci.yaml, så som 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 är active eller disabled_manually. Det är samma inställning som knapparna ändrar, så gränssnittet och API:t är alltid överens.
• name är arbetsflödets name:, eller filnamnet om det saknas. created_at och updated_at är båda tidpunkten för standard-branchens senaste commit, som på Gitea, inte filens egen historik.
• Att stänga av och slå på kräver admin för repot, precis som knapparna. En användare med skrivbehörighet får 403. Det är striktare än Gitea, som låter användare med skrivbehörighet göra det.
• 404 för en fil som inte är ett arbetsflöde på standard-branchen. Ett skrivfel, en fil på en annan branch eller en fil som inte är .yml/.yaml i arbetsflödeskatalogen avvisas i stället för att registreras.
• Ett arkiverat repo svarar 423 på slå på och stäng av. Det kan fortfarande läsas.
• Båda anropen är idempotenta. Att stänga av ett avstängt arbetsflöde returnerar 204 och ändrar ingenting.
• Vad “avstängt” stoppar: körningar från händelser (push, pull request och resten), schemalagda körningar och omkörningar av dess befintliga körningar (POST .../rerun svarar 422). En manuell start (POST .../actions/workflows/<workflow_id>/dispatches) körs fortfarande, precis som Run workflow i gränssnittet.
• ffp_*-tokens kan inte anropa de här routes. De kräver en Forgejo-PAT (scope write:repository för att slå på/stänga av) eller en session, precis som avbryt och kör om.

Hämta arbetsflödesloggar programmatiskt

Forgejos webbgränssnitt visar loggarna för action-körningar interaktivt. För programmatisk åtkomst (felnotifierare, felsökningsskript, exporter för regelefterlevnad, AI-agenter som triagerar fel) finns två endpoints, beroende på vilken typ av token du har:

Med en Forgejo-PAT eller sessionscookie

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

Returnerar text/plain: alla körningens jobb sammanfogade, med rubrikerna === job: <name> (status=<status>, attempt=<n>) === mellan jobben. <run_id> är det globala id som Forgejo returnerar från GET /api/v1/repos/<owner>/<repo>/actions/runs (samma id som webbgränssnittet visar i /<owner>/<repo>/actions/runs/<n>). Behörighetskontrollen är Forgejos vanliga läskontroll för repot; botanvändare med rätt organisationsmedlemskap fungerar på samma sätt som mänskliga användare.

Med en fremforge-API-PAT (ffp_*)

Om din token börjar med ffp_, vilket inkluderar PAT:er som skapats i administrationsgränssnittet, tokens från POST /_app/api/v1/auth/token-exchange (OIDC-utbyte) och tokens som utfärdas av POST /_app/api/v1/oauth/token (client_credentials), känner Forgejo inte igen den. Använd i stället fremforges API-proxy:

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

Samma svarsform (text/plain, sammanfogade jobb, rubriker mellan dem). Scope som krävs: runners:read. Proxyn kontrollerar tokens koppling till organisationen (<org> i URL:en måste matcha tokens organisation) innan den vidarebefordrar till Forgejo med en systemuppgift för inloggning. Systemuppgiften lämnar aldrig plattformen, så en läckt PAT från en kund kan bara läsa den egna organisationens loggar.

Båda endpoints returnerar samma innehåll, så en anropare som byter autentiseringsform behöver bara ändra URL:en och Authorization-headern.

Om tillfällig lösning. Proxyn /api/v1/orgs/<org>/repos/<repo>/... är en tillfällig brygga tills Forgejo uppströms stöder API-domänens tokens (ffp_*) på sin egen endpoint /api/v1/repos/<owner>/<repo>/.... När det finns tas proxyn bort, och ffp_*-tokens går till samma sökväg som Forgejo-PAT:er. Svarsformen förblir identisk; bara URL-formen ändras.

När loggarna inte är tillgängliga

• 404 — körningen hittades inte, eller tillhör inte repot i URL:en.
• 410 — loggarna har rensats av rensningsjobbet (action-körningar äldre än lagringstiden).
• 502 — Forgejos origin går inte att nå. Försök igen; om det kvarstår, kontrollera status.frem.sh.

Korsreferenser

• CI-runners: tillgängliga runner-etiketter, egna runners (BYO), gränser för samtidighet
• Secrets: omfång för secrets, rotation, OIDC som alternativ
• Marketplace-kompatibilitet: kompatibilitetsmatris för actions
• OIDC-tokenfederation: nyckellös driftsättning i molnet från jobb
• Paketregister: publicera paket från CI