Über dieses Tool
Die meisten Testsuites brauchen dasselbe CI-Grundgerüst: Code auschecken, eine Runtime installieren, Abhängigkeiten und Browser installieren, die Tests ausführen und den Report behalten, wenn etwas fehlschlägt. Dieser Generator schreibt diesen Workflow für Playwright (TypeScript), Cypress, Selenium mit Java und Maven oder pytest und verwendet aktuelle Hauptversionen der offiziellen Actions (checkout@v4, setup-node@v4, setup-java@v4, setup-python@v5, cache@v4, upload-artifact@v4). Für Playwright kann er die Suite mit --shard=i/n auf parallele Jobs verteilen und die Blob-Reports anschließend zu einem HTML-Report zusammenführen, nach dem dokumentierten Muster von Playwright. Geplante Läufe verwenden 5-Felder-Cron in UTC, wie GitHub Actions es verlangt.
So funktioniert es
- Wählen Sie Framework und Runtime-Version und dann die Trigger: push, pull_request, einen Cron-Zeitplan oder manuelles workflow_dispatch.
- Wählen Sie Browser und für Playwright die Anzahl der Shards. Lassen Sie Caching und Report-Upload aktiviert, sofern Sie keinen Grund dagegen haben.
- Kopieren oder laden Sie das YAML herunter, speichern Sie es unter .github/workflows/ in Ihrem Repository und prüfen Sie, ob Befehle wie npm ci oder pip install -r requirements.txt zu Ihrem Projekt passen.
FAQ zu GitHub-Actions-Workflow-Generator für Tests
Warum läuft der Zeitplan zu einer anderen Stunde als erwartet?
GitHub Actions wertet Cron in UTC aus; rechnen Sie also von Ihrer lokalen Zeitzone um. Geplante Läufe können zu Stoßzeiten auch verspätet starten, und in öffentlichen Repositories werden geplante Workflows nach 60 Tagen ohne Repository-Aktivität automatisch deaktiviert.
Wie funktioniert das Playwright-Sharding hier?
Eine Matrix startet einen Job pro Shard, und jeder führt npx playwright test --shard=i/n mit dem Blob-Reporter aus. Ein nachgelagerter Job lädt alle Blob-Reports herunter und führt npx playwright merge-reports aus, um ein einzelnes HTML-Report-Artefakt zu erzeugen.
Warum gibt es für jeden Browser ein --project-Flag?
Playwright wählt Browser über Projekte, die in playwright.config.ts definiert sind. Der erzeugte Befehl übergibt --project=<name> für jeden gewählten Browser, diese Projektnamen müssen also in Ihrer Konfiguration existieren. Entfernen Sie das Flag, um alle Projekte auszuführen.
Wohin gehören Zugangsdaten wie das Passwort eines Testnutzers?
Speichern Sie sie als Repository- oder Environment-Secrets und referenzieren Sie sie mit ${{ secrets.NAME }} in einem env-Block. Committen Sie sie niemals in der Workflow-Datei.