Kompatibilitet for de 20 mest brugte Marketplace-actions

De fleste Marketplace-actions virker på fremforge uden ændringer, fordi fremforges runnere henter actionkoden gennem Forgejo-pull-mirrors af GitHub-udgivere, som fremverk driver. En workflows uses: actions/checkout@v4 peger på https://frem.sh/actions/checkout, et Forgejo-pull-mirror af github.com/actions/checkout, der synkroniseres med upstream hver 8. time. Ingen kørsel af kunders workflows når github.com direkte: runnerne ser kun den spejlede kopi, der ligger i EU, hvilket opfylder forpligtelsen i DPA’ens bilag A.6. Forgejo Actions-runtimen stiller de samme miljøvariabler til rådighed som GitHub Actions (GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL osv.), så en workflows uses: actions/checkout@v4-direktiv slås op gennem mirroret, uden at du mærker det.

Spejlede upstream-udgivere (pr. 2026-06-02)

Disse GitHub-udgivere er spejlet som Forgejo-pull-mirrors på frem.sh og virker uden problemer fra enhver kundes workflow:

• 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

Har du brug for en action fra en udgiver, der ikke står ovenfor, så send en anmodning om et mirror. Vi tilføjer et nyt pull-mirror af github.com/<publisher>/<repo>, og dit workflow kører uden problemer ved næste kørsel. Anmodninger om mirrors er typisk klaret inden for én arbejdsdag. Reserverede udgivernavne (aws-actions, azure, microsoft, sigstore osv.) er låst på forhånd i Forgejos identitetslag, så ingen kundetenant kan tage dem og smugle ondsindet kode ind gennem dine workflows.

Denne matrix dækker de 20 mest downloadede actions. Hver post er markeret med sit verificeringsniveau:

• Kodegennemgået: vurderet ud fra actionens kildekode og rapporter fra Forgejo-fællesskabet; endnu ikke kørt på en rigtig runner hostet af fremforge.
• Runner-verificeret: kørt på en rigtig runner hostet af fremforge; resultatet er bekræftet i praksis.

Runner-verificerede poster kommer til, efterhånden som tjeklisten over blokeringer for lanceringen i fase 1 bliver gennemgået.

Forklaring af status

• ✅ Virker som den er: kører uændret; workflows kan flyttes uden ændringer.
• ⚠️ Virker med bemærkning: kører, men en bestemt adfærd er anderledes, eller en forudsætning skal være opfyldt. Bemærkningen beskriver, hvad du skal gøre.
• 🔧 Kræver wrapper: en lille wrapper eller composite action genskaber kompatibiliteten. Koden til wrapperen følger med.
• ❌ Intet tilsvarende: afhænger af infrastruktur, der kun findes hos GitHub, og kan ikke køre mod fremforge. Et alternativ anbefales.

Hvad vi lover at dække

De 20 mest brugte actions på GitHub Marketplace på lanceringstidspunktet. Listen gennemgås hvert kvartal; en action, der falder ud af top 20, bliver i matrixen, indtil brugsdata begrunder at fjerne den.

Kompatibilitetsmatrix

Opsætning af OIDC-føderation

Actions, der bruger OIDC (azure/login, aws-actions/configure-aws-credentials, google-github-actions/auth), kræver et engangstrin, hvor fremforge registreres som en betroet OIDC-udsteder hos cloududbyderen.

fremforges OIDC-discovery-endpoint: https://frem.sh/_app/runner/oidc/.well-known/openid-configuration (ét fælles endpoint for alle tenants; iss-claimet i hvert token, en runner udsteder, er https://frem.sh/_app/runner/oidc). Adskillelse af tillid pr. tenant håndhæves ved at fastlåse betingelser i cloudens trust-politik på JWT-claimet repository_owner, samme mønster som i GitHub Actions.

Den fulde trin-for-trin-vejledning til Azure AD, AWS IAM og GCP Workload Identity står i runbooken til opsætning af OIDC for runnere.

Build af container-images

docker build og docker compose kører direkte på runneren, og docker/build-push-action og docker/setup-buildx-action virker uændret (se Runner-images for runnermodellen og adgangen til Docker). kaniko er forudinstalleret som et alternativ uden daemon, når du vil have hurtigere koldstart eller caching af lag i et eksternt registry:

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

Til ren kopiering, omtagging og push af images mellem registries virker den forudinstallerede skopeo uden en Docker-daemon. Se Runner-image for hele mønstret.

Når du finder et hul

Finder du en Marketplace-action, der burde være i top 20, og som vi ikke har vurderet kompatibiliteten for, eller en action på listen her, der ikke opfører sig som beskrevet, så skriv til support@frem.sh med en emnelinje, der starter med MARKETPLACE COMPAT -. Vi verificerer den og opdaterer matrixen.

Ud over top 20

De fleste andre Marketplace-actions virker bare. Undtagelserne er actions, der:

• Er afhængige af GitHub-interne API-endpoints (Codespaces API, Copilot API, GitHub Packages’ container-registry-API ud over almindelig OCI-push/pull).
• Har GitHubs OIDC-udsteder-URL (https://token.actions.githubusercontent.com) hårdkodet i stedet for at læse ACTIONS_ID_TOKEN_REQUEST_URL.
• Kræver GitHub-specifik godkendelse ud over GITHUB_TOKEN.

For ikke-verificerede actions uden for top 20: prøv dem. De fleste virker. De få, der ikke gør, dokumenterer vi, og så laver vi enten en wrapper eller beskriver hullet i migreringsvejledningerne.

Se også

• Runner-images: tilgængelige runner-labels, og hvilket image hver af dem svarer til.
• Opsætning af OIDC for runnere: opsæt cloududbyderens tillid til godkendelses-actions, der bruger OIDC.
• Migreringsvejledninger: hvordan referencer til Marketplace-actions flyttes med under en platformsmigrering.
• Offentligt REST API: fremforges API-flade til actions, der skal kalde tilbage til platformen.