Was dieser Builder macht
Ein GitHub-Actions-Workflow ist eine YAML-Datei, die GitHub sagt, was zu tun ist, wenn im Repo etwas passiert: Tests bei jedem Push, Docker-Image bei jedem Tag, Deploy bei jedem Merge in main. Die Syntax ist in der Theorie simpel und in der Praxis voller kleiner Fallen: Einrueckung zaehlt, der `on`-Key wird in YAML 1.1 als Boolean `true` fehlgelesen, Matrizen nutzen Bracket-Notation, `needs` akzeptiert String oder Liste. Ein vergessenes Leerzeichen und der ganze Workflow weigert sich zu laufen.
Dieser Builder schreibt die Datei fuer dich. Preset waehlen (Node-CI, Docker Build & Push, Vercel-Deploy, pytest-Matrix, statische Seite auf Pages), Trigger und Jobs in simplen Formularen bearbeiten, und das rechte Panel zeigt das exakte YAML, das du in `.github/workflows/ci.yml` einfuegen kannst. Jede Option hat einen Klartext-Hinweis, und die Validierung flaggt fehlende Namen, leere Trigger und falsche Job-Referenzen.
Alles laeuft im Browser. Kein Upload, kein Account, kein echter Workflow wird hier gestartet. Der Output ist derselbe Text, den du von Hand schreiben wuerdest, nur ohne Tippfehler.
So benutzt du es
- Ein Preset oben waehlen: Node.js-CI, Docker Build & Push, Vercel-Deploy, pytest-Matrix, statische Seite auf Pages. Das Formular fuellt sinnvolle Defaults aus.
- Den Workflow-Namen setzen (erscheint im Actions-Tab) und optionale Permissions als `KEY=value`-Paare.
- Trigger toggeln: push (mit Branch-Liste), pull_request (mit Branch-Liste), schedule (Cron-Expression), workflow_dispatch (manueller Run aus der UI).
- Jobs in Tabs ergaenzen. Pro Job setzen: eindeutige id (genutzt von `needs:` und der URL), Display-Name, Runner, optionales needs und Job-Level-env.
- Matrix einschalten, wenn du ueber Node-Versionen, OS oder eine andere Achse fan-outen willst. Zeilen `key=value1, value2, ...` ergaenzen.
- Steps in Reihenfolge ergaenzen. Jeder Step ist entweder ein Shell-Skript (`run:`) oder eine wiederverwendete Action (`uses:`). Typische Actions sind einen Klick entfernt: checkout, setup-node, cache, upload-artifact, docker buildx.
- Im Vorschau-Panel Copy klicken oder Download zum Speichern als `ci.yml`, dann in `.github/workflows/ci.yml` deines Repos committen. GitHub greift sie automatisch auf und der naechste Push triggert.
Wann das nuetzlich ist
Sieben konkrete Situationen, in denen ein GitHub-Actions-Builder echte Zeit spart:
- Erster Workflow in einem neuen Repo. Builder oeffnen, "Node.js CI" waehlen, das Test-Script anpassen, kopieren, committen. In zwei Minuten erledigt statt in den Docs nach der richtigen Syntax zu fischen.
- Matrix-Tests auf mehreren Node- oder Python-Versionen. Die Matrix-Syntax ist fummelig (`fail-fast`, Brackets vs Listen). Der Builder schreibt sie korrekt, und die Vorschau zeigt genau, was laeuft.
- Docker Build & Push zu GHCR oder Docker Hub. Die offizielle `docker/build-push-action` braucht ein paar `with:`-Keys in der richtigen Reihenfolge. Preset waehlen, Tag aendern, ausspielen.
- Eine Next.js-/Vite-/Astro-Seite auf Vercel oder GitHub Pages deployen. Beide Flows haben eine bekannte Sequenz: checkout, install, build, deploy. Der Builder codiert die Sequenz und du fuellst nur die Secret-Namen.
- Geplante Jobs: naechtliche Backups, woechentliche Cleanups, monatliche Reports. `schedule:` toggeln, Cron-Expression einfuegen, der Rest ist wie jeder andere Job.
- Manuelle Workflows per Button getriggert (`workflow_dispatch`). Ein Toggle und der Workflow erscheint unter dem "Run workflow"-Button im Actions-Tab.
- Multi-Job-Pipelines mit Abhaengigkeiten: Build dann Deploy, Build dann Test dann Deploy. Die Chips-UI fuer `needs:` macht die Reihenfolge offensichtlich.