Kompatibilität der Top-20-Actions aus dem Marketplace

Die meisten Actions aus dem Marketplace funktionieren in fremforge ohne Änderung, weil die Runner von fremforge den Code von Actions über Forgejo-Pull-Mirrors der Upstream-Publisher auf GitHub auflösen, die fremverk betreibt. Ein uses: actions/checkout@v4 in einem Workflow wird zu https://frem.sh/actions/checkout aufgelöst, einem Forgejo-Pull-Mirror von github.com/actions/checkout, der alle 8 Stunden mit dem Upstream synchronisiert wird. Keine Ausführung eines Kunden-Workflows erreicht github.com direkt: Runner sehen immer nur die gespiegelte Kopie, die in der EU liegt, und erfüllen so die Zusage aus Anhang A.6 des AVV. Die Laufzeitumgebung von Forgejo Actions stellt dieselben Umgebungsvariablen bereit wie GitHub Actions (GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL usw.), sodass die Anweisung uses: actions/checkout@v4 eines Workflows transparent über den Mirror aufgelöst wird.

Gespiegelte Upstream-Publisher (Stand 2026-06-02)

Diese Publisher auf GitHub sind als Forgejo-Pull-Mirrors auf frem.sh gespiegelt und lassen sich aus jedem Kunden-Workflow problemlos auflösen:

• 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

Brauchst du eine Action von einem Publisher, der oben nicht steht, stell eine Mirror-Anfrage. Wir legen einen neuen Pull-Mirror von github.com/<publisher>/<repo> an, und dein Workflow läuft beim nächsten Start problemlos. Mirror-Anfragen sind in der Regel innerhalb eines Werktags erledigt. Reservierte Publisher-Namen (aws-actions, azure, microsoft, sigstore usw.) sind auf der Identitätsebene von Forgejo vorab gesperrt, damit kein Kundenmandant sie besetzen und über deine Workflows Schadcode einschleusen kann.

Diese Matrix deckt die 20 am häufigsten heruntergeladenen Actions ab. Jeder Eintrag ist mit seiner Prüfstufe gekennzeichnet:

• Code-reviewed: anhand des Quellcodes der Action und Berichten aus der Forgejo-Community bewertet; noch nicht auf einem echten gehosteten Runner von fremforge ausgeführt.
• Runner-verified: auf einem echten gehosteten Runner von fremforge ausgeführt; das Ergebnis ist empirisch bestätigt.

Einträge der Stufe Runner-verified kommen hinzu, während die Checkliste der Launch-Blocker für Phase 1 abgearbeitet wird.

Legende

• ✅ Funktioniert unverändert: läuft ohne Änderung; Workflows lassen sich ohne Anpassung übernehmen.
• ⚠️ Funktioniert mit Hinweis: läuft, aber ein bestimmtes Verhalten weicht ab oder eine Voraussetzung muss erfüllt sein. Der Hinweis beschreibt, was zu tun ist.
• 🔧 Braucht einen Wrapper: ein kleiner Wrapper oder eine Composite Action stellt die Kompatibilität her. Der Code des Wrappers wird bereitgestellt.
• ❌ Keine Entsprechung: hängt von Infrastruktur ab, die es nur bei GitHub gibt, und kann nicht gegen fremforge laufen. Eine Alternative wird empfohlen.

Abdeckungszusage

Die 20 meistgenutzten Actions im GitHub Marketplace zum Zeitpunkt des Launchs. Die Liste wird vierteljährlich überprüft; eine Action, die aus den Top 20 herausfällt, bleibt in der Matrix, bis ein Nutzungssignal sie entfernt.

Kompatibilitätsmatrix

OIDC-Föderation einrichten

Actions, die OIDC verwenden (azure/login, aws-actions/configure-aws-credentials, google-github-actions/auth), brauchen einen einmaligen Konfigurationsschritt, um fremforge beim Cloud-Anbieter als vertrauenswürdigen OIDC-Issuer zu registrieren.

Der OIDC-Discovery-Endpunkt von fremforge: https://frem.sh/_app/runner/oidc/.well-known/openid-configuration (ein einziger globaler Endpunkt für alle Mandanten; der Claim iss jedes vom Runner ausgestellten Tokens ist https://frem.sh/_app/runner/oidc). Die Trennung des Vertrauens pro Mandant wird erzwungen, indem die Bedingungen der Vertrauensrichtlinie in der Cloud auf den JWT-Claim repository_owner festgelegt werden, das zu GitHub Actions kompatible Muster.

Die vollständigen Schritt-für-Schritt-Anleitungen für Azure AD, AWS IAM und GCP Workload Identity stehen im Runbook zum Einrichten von Runner-OIDC.

Container-Images bauen

docker build und docker compose laufen nativ auf dem Runner; docker/build-push-action und docker/setup-buildx-action funktionieren unverändert (siehe Runner-Images zum Runner-Modell und zur Verfügbarkeit von Docker). kaniko ist als daemonlose Alternative vorinstalliert, wenn du einen schnelleren Kaltstart oder Layer-Caching in einer entfernten Registry möchtest:

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

Um Images nur zwischen Registrys zu kopieren, neu zu taggen oder zu pushen, funktioniert das vorinstallierte skopeo ohne Docker-Daemon. Das vollständige Muster steht unter Runner-Image.

Wenn du eine Lücke findest

Findest du eine Action aus dem Marketplace, die in die Top 20 gehört und deren Kompatibilität wir noch nicht bewertet haben, oder verhält sich eine hier aufgeführte Action nicht wie dokumentiert, melde das an support@frem.sh mit einem Betreff, der mit MARKETPLACE COMPAT - beginnt. Wir prüfen es und aktualisieren die Matrix.

Jenseits der Top 20

Die meisten anderen Actions aus dem Marketplace funktionieren einfach. Ausnahmen sind Actions, die:

• sich auf interne API-Endpunkte von GitHub stützen (Codespaces-API, Copilot-API, die API der Container-Registry von GitHub Packages über Standard-OCI-Push und -Pull hinaus);
• die OIDC-Issuer-URL von GitHub (https://token.actions.githubusercontent.com) fest eincodieren, statt ACTIONS_ID_TOKEN_REQUEST_URL zu lesen;
• eine GitHub-spezifische Authentifizierung über GITHUB_TOKEN hinaus verlangen.

Für ungeprüfte Actions außerhalb der Top 20 gilt: Probier es aus. Die meisten funktionieren. Die wenigen, die es nicht tun, melde uns, und wir liefern entweder einen Wrapper oder benennen die Lücke in den Migrationsleitfäden.

Siehe auch

• Runner-Images, verfügbare Runner-Labels und welches Image zu welchem gehört.
• Runner-OIDC einrichten, Vertrauen beim Cloud-Anbieter für Actions mit OIDC-basierter Authentifizierung konfigurieren.
• Migrationsleitfäden, wie Verweise auf Actions aus dem Marketplace bei einer Plattformmigration übernommen werden.
• Öffentliche REST-API, die API von fremforge für Actions, die die Plattform zurückrufen müssen.