Kompatibilitet for de 20 mest brukte Marketplace-actions

De fleste Marketplace-actions virker på fremforge uten endringer, fordi fremforges runnere henter action-koden gjennom Forgejo-pull-speil av upstream-utgivere på GitHub, driftet av fremverk. En workflows uses: actions/checkout@v4 løses opp til https://frem.sh/actions/checkout, et Forgejo-pull-speil av github.com/actions/checkout som synkroniseres med upstream hver 8. time. Ingen kjøring av kunders workflower når github.com direkte: runnerne ser bare den speilede kopien som holdes inne i EU, i tråd med forpliktelsen i DPA vedlegg A.6. Forgejo Actions-kjøretiden eksponerer de samme miljøvariablene som GitHub Actions (GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL osv.), så en workflows uses: actions/checkout@v4-direktiv løses opp gjennom speilet uten at du merker det.

Speilede upstream-utgivere (per 2026-06-02)

Disse GitHub-utgiverne er speilet som Forgejo-pull-speil på frem.sh og løses opp uten problemer fra enhver kundeworkflow:

• actions/: checkout, setup-node, setup-python, setup-go, setup-java, setup-dotnet, upload-artifact, download-artifact, cache
• docker/: login-action, setup-buildx-action, build-push-action
• pnpm/: action-setup
• step-security/: harden-runner
• aws-actions/: configure-aws-credentials
• azure/: login
• google-github-actions/: auth
• peter-evans/: create-pull-request
• dorny/: paths-filter, test-reporter
• softprops/: action-gh-release
• sonarsource/: sonarcloud-github-action

Hvis du trenger en action fra en utgiver som ikke står på listen over, kan du sende en forespørsel om speiling. Vi legger til et nytt pull-speil av github.com/<publisher>/<repo>, og workflowen din kjører uten problemer ved neste utsendelse. Forespørsler om speiling blir som regel fullført innen én virkedag. Reserverte utgivernavn (aws-actions, azure, microsoft, sigstore osv.) er låst på forhånd i Forgejos identitetslag, så ingen kunde kan legge beslag på dem og smugle ondsinnet kode inn i workflowene dine.

Denne matrisen dekker de 20 mest nedlastede actions. Oppføringene er merket med verifiseringsnivå:

• Code-reviewed: vurdert ut fra kildekoden til actionen og rapporter fra Forgejo-fellesskapet; ennå ikke kjørt på en hostet fremforge-runner i drift.
• Runner-verified: kjørt mot en ekte hostet fremforge-runner; resultatet er bekreftet i praksis.

Oppføringer merket Runner-verified kommer etter hvert som sjekklisten over hindringer for lansering i fase 1 gjennomføres.

Forklaring av status

• ✅ Virker som den er: kjører uendret; workflower kan flyttes uten endringer.
• ⚠️ Virker, med merknad: kjører, men en bestemt oppførsel er annerledes, eller en forutsetning må være oppfylt. Merknaden beskriver hva du må gjøre.
• 🔧 Trenger innpakning: en liten innpakning eller en sammensatt action gjenoppretter kompatibiliteten. Koden for innpakningen følger med.
• ❌ Ingen tilsvarende: avhenger av infrastruktur som bare finnes hos GitHub, og kan ikke kjøre mot fremforge. Et alternativ anbefales.

Hva vi lover å dekke

De 20 mest brukte actions på GitHub Marketplace ved lansering. Listen gjennomgås hvert kvartal; en action som faller ut av topp 20, blir stående i matrisen til bruksdata tilsier at den fjernes.

Kompatibilitetsmatrise

Oppsett av OIDC-føderasjon

Actions som bruker OIDC (azure/login, aws-actions/configure-aws-credentials, google-github-actions/auth), krever et engangsoppsett der fremforge registreres som en klarert OIDC-utsteder hos skyleverandøren.

fremforges OIDC-discovery-endepunkt: https://frem.sh/_app/runner/oidc/.well-known/openid-configuration (ett globalt endepunkt for alle kunder; iss-claimen på hvert token en runner utsteder, er https://frem.sh/_app/runner/oidc). Isolasjon av tillit per kunde håndheves ved å låse betingelsene i skyens tillitspolicy til JWT-claimen repository_owner, det samme mønsteret som i GitHub Actions.

Fullstendige steg-for-steg-instruksjoner for Azure AD, AWS IAM og GCP Workload Identity står i veiledningen for OIDC på runnere.

Bygging av containerimager

docker build og docker compose kjører direkte på runneren, så docker/build-push-action og docker/setup-buildx-action virker uendret (se Runner-imager for runnermodellen og tilgangen til Docker). kaniko er forhåndsinstallert som et alternativ uten daemon når du vil ha raskere kaldstart eller bufring av lag i et eksternt register:

- name: Build + push image (kaniko)
  run: |
    /usr/local/bin/kaniko \
      --context=$GITHUB_WORKSPACE \
      --dockerfile=Dockerfile \
      --destination=registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA

For ren kopiering, ny tagging og push av imager mellom registre virker den forhåndsinstallerte skopeo uten Docker-daemon. Se Runner-image for hele mønsteret.

Når du finner et hull

Hvis du finner en Marketplace-action som burde vært blant de 20, og som vi ikke har vurdert kompatibiliteten for, eller en action på listen som ikke oppfører seg som dokumentert, sender du en henvendelse til support@frem.sh med en emnelinje som starter med MARKETPLACE COMPAT -. Vi kontrollerer og oppdaterer matrisen.

Utover topp 20

De fleste andre Marketplace-actions virker uten videre. Unntakene er actions som:

• Er avhengige av interne API-endepunkter hos GitHub (Codespaces-API-et, Copilot-API-et, API-et for containerregisteret i GitHub Packages utover vanlig OCI push/pull).
• Har GitHubs OIDC-utsteder-URL (https://token.actions.githubusercontent.com) hardkodet i stedet for å lese ACTIONS_ID_TOKEN_REQUEST_URL.
• Krever GitHub-spesifikk autentisering utover GITHUB_TOKEN.

For actions utenfor topp 20 som ikke er verifisert: prøv. De fleste virker. De få som ikke gjør det, dokumenterer vi, og enten leverer vi en innpakning, eller så beskriver vi hullet i migreringsveiledningene.

Se også

• Runner-imager: tilgjengelige runner-etiketter og hvilket image hver av dem tilsvarer.
• OIDC på runnere: sett opp tillit hos skyleverandøren for actions som autentiserer med OIDC.
• Migreringsveiledninger: hvordan referanser til Marketplace-actions flyttes ved en plattformmigrering.
• Offentlig REST-API: fremforges API-flate for actions som må kalle tilbake til plattformen.