What this builder does
A GitHub Actions workflow is a YAML file that tells GitHub what to do when something happens in your repo: run tests on every push, build a Docker image on every tag, deploy on every merge to main. The syntax is simple in theory and full of small traps in practice: indentation matters, the `on` key gets misread as the boolean `true` in YAML 1.1, matrices use bracket notation, `needs` accepts a string or a list. One missed space and the whole workflow refuses to run.
This builder writes that file for you. Pick a preset (Node CI, Docker build and push, Vercel deploy, pytest matrix, static site to Pages), edit triggers and jobs in plain forms, and the right pane shows the exact YAML you can drop into `.github/workflows/ci.yml`. Every option has a plain-language hint and validation flags missing names, empty triggers, and bad job references.
Everything runs in your browser. No upload, no account, no real workflow is started here. The output is the same text you would write by hand, only without the typos.
How to use it
- Pick a preset at the top: Node.js CI, Docker build and push, Vercel deploy, pytest matrix, static site to Pages. The form fills in sensible defaults.
- Set the workflow name (shows up in the Actions tab) and optional permissions as `KEY=value` pairs.
- Toggle triggers: push (with branch list), pull_request (with branch list), schedule (cron expression), workflow_dispatch (manual run from the UI).
- Add jobs in tabs. For each job set: a unique id (used by `needs:` and the URL), a display name, the runner, optional needs, and job-level env.
- Turn on matrix if you want to fan out across Node versions, OS, or any axis. Add `key=value1, value2, ...` rows.
- Add steps in order. Each step is either a shell script (`run:`) or a reused action (`uses:`). Common actions are one click away: checkout, setup-node, cache, upload-artifact, docker buildx.
- Click Copy in the preview pane, or Download to save as `ci.yml`, then commit to `.github/workflows/ci.yml` in your repo. GitHub picks it up automatically and the next push triggers it.
When this is useful
Seven concrete situations where a GitHub Actions builder saves real time:
- First workflow in a new repo. Open the builder, pick "Node.js CI", change the test script, copy, commit. Done in two minutes instead of fishing through the docs for the right syntax.
- Matrix tests on multiple Node or Python versions. The matrix syntax is fiddly (`fail-fast`, brackets vs lists). The builder writes it correctly and the preview shows you exactly what runs.
- Docker build and push to GHCR or Docker Hub. The official `docker/build-push-action` needs a few `with:` keys in the right order. Pick the preset, change the tag, ship.
- Deploying a Next.js / Vite / Astro site to Vercel or GitHub Pages. Both flows have a well-known sequence: checkout, install, build, deploy. The builder encodes the sequence and you just fill the secret names.
- Scheduled jobs: nightly backups, weekly cleanups, monthly reports. Toggle `schedule:`, paste a cron expression, the rest is the same as any other job.
- Manual workflows triggered by a button (`workflow_dispatch`). One toggle and the workflow shows up under the "Run workflow" button in the Actions tab.
- Multi-job pipelines with dependencies: build then deploy, build then test then deploy. The chips UI for `needs:` makes the order obvious.