GitHub Actions Workflow Generator

Pick a stack and triggers, get a ready-to-commit .github/workflows YAML file using current action versions

Stack

Workflow name

TriggersPushPull requestManual (workflow_dispatch)

Branches for push / pull request, comma-separated

Runner

Node versions (matrix)

Package manager

StepsLintTestBuild

.github/workflows/ci.yml

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ["20", "22"]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Action versions are pinned to their current major release. Version numbers in matrices are quoted on purpose — unquoted, YAML reads 3.10 as the number 3.1.

About this tool

The ToolNinja GitHub Actions Workflow Generator builds a ready-to-commit CI workflow from a few choices: stack (Node.js, Python, Go, or a Docker image pushed to GitHub Container Registry), triggers, runner, version matrix, and which steps to run. The generated YAML pins each action (checkout, setup-node, setup-python, setup-go, and the Docker build actions) to its current major version, so you don't start from a blog post's outdated v2 or v3 snippet. Dependency caching is set up where the setup action supports it, and version numbers in matrices are quoted so YAML doesn't read 3.10 as 3.1. The Docker option logs in to GHCR with the built-in GITHUB_TOKEN, tags images by branch, PR, and commit SHA, uses GitHub's build cache, and skips pushing on pull requests.

When to use it

→Adding CI to a new repository without writing workflow YAML from scratch
→Testing a Node or Python project across several runtime versions with a matrix
→Building and pushing a Docker image to GitHub Container Registry on every push
→Updating an old workflow to current action versions

Tips

◆Save the file under .github/workflows/ in your repository; GitHub picks up any .yml file there automatically.
◆Quote version numbers in YAML. Unquoted, 3.10 becomes the number 3.1 and you'll silently test the wrong Python version.
◆For pnpm, add a "packageManager" field to package.json (for example "pnpm@10.0.0") so the pnpm setup action knows which version to install.

Frequently asked questions

Do I need to add any secrets?

Not for the Node, Python, and Go workflows. The Docker workflow uses the built-in GITHUB_TOKEN to push to GitHub Container Registry, which works without extra setup as long as the workflow has packages: write permission. The generated file includes that permission.

Why does the Docker workflow not push on pull requests?

Pull requests from forks don't get write access to your registry, and you usually don't want an image published for unmerged code. The workflow still builds on pull requests, so a broken Dockerfile fails CI before merge.

How do I run the workflow manually?

Enable the 'Manual (workflow_dispatch)' trigger. A 'Run workflow' button then appears on the workflow's page in the repository's Actions tab.