What's the difference between the push and pull_request triggers?

The push trigger runs the workflow when commits land directly on one of the specified branches (e.g. after a merge to main). The pull_request trigger runs when a PR targeting one of the specified branches is opened or updated, letting you validate changes before they merge. Most repositories enable both.

How does the matrix strategy toggle work?

Enabling it adds a `strategy.matrix` block with the versions you list (as `node-version` or `python-version`, depending on your setup choice), and the setup step then references `${{ matrix.node-version }}` (or the Python equivalent) instead of a fixed version, so the job runs once per listed version in parallel.

Why add a permissions block at all?

GitHub Actions workflows are granted broad default permissions on the repository's GITHUB_TOKEN unless explicitly restricted. Setting `permissions: contents: read` (or omitting write access entirely) follows the principle of least privilege, limiting what a compromised or misbehaving action could do to your repository.

Does this cover deploy workflows, releases, or reusable workflows?

No, it generates a single straightforward CI job (checkout, optional language setup, one run command), optionally matrixed. Deployment-specific steps, `workflow_call` reusable workflows, and release automation aren't covered and would need to be added afterward.

GitHub Actions Generator - Build a CI Workflow YAML

Overview

Introduction

A GitHub Actions workflow file looks simple until you need a version matrix or a permissions block, at which point the nesting under `strategy.matrix` and referencing `${{ matrix.* }}` correctly becomes easy to get wrong.

This tool generates a complete workflow YAML from a form: triggers, a job with optional Node/Python setup, an optional matrix strategy, and a permissions block.

What Is GitHub Actions Workflow Generator?

A form-driven generator for GitHub Actions CI workflows. You configure push and/or pull_request triggers with branch filters, a job name and runner (runs-on), an optional Node or Python setup step, a single run command, an optional version matrix, and a permissions level.

The output is a complete workflow YAML file ready to save under `.github/workflows/`.

How GitHub Actions Workflow Generator Works

Enabling the matrix strategy adds a `strategy.matrix` block using the version list you provide, and automatically rewrites the setup step's version field to reference `${{ matrix.node-version }}` or `${{ matrix.python-version }}` instead of a fixed value.

The permissions selector maps to GitHub's own three common levels: no explicit block (inherits repository defaults), read-only contents, or contents write access, each rendered as a top-level `permissions:` key.

When To Use GitHub Actions Workflow Generator

Use it when adding CI to a new GitHub repository and you want a correct starting workflow instead of copy-pasting from an unrelated project's `.github/workflows/`.

It's also useful for adding a version matrix to an existing single-version workflow, or tightening an existing workflow's permissions.

Often used alongside .gitignore Generator, GitLab CI Generator and Conventional Commit Message Generator.

Features

Advantages

Automatically rewires the setup step to use `${{ matrix.* }}` when the matrix strategy is enabled, a detail that's easy to forget when adding a matrix to an existing workflow by hand.
Generates a `permissions:` block by default guidance rather than leaving your workflow on GitHub's broader legacy default permissions.
Produces correctly indented, valid workflow YAML for both push and pull_request triggers with branch filters.

Limitations

Only Node and Python setup actions are covered (via actions/setup-node and actions/setup-python); other languages need their setup step added manually.
Generates a single job; multi-job workflows with dependencies (`needs:`), or reusable/called workflows, aren't covered.

Examples

A Node.js CI workflow with a version matrix

Input

on: push (main), pull_request (main); job: build, runs-on: ubuntu-latest; setup: node; matrix: 18, 20; run: npm test

Output

name: CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

permissions:
  contents: read

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

The matrix toggle both adds the strategy block and rewrites the setup-node version to reference matrix.node-version.

Best Practices & Notes

Best Practices

Set `permissions: contents: read` (or more restrictive) as the default and grant additional scopes (like `contents: write` for a release job) only on the specific job that needs them.
Trigger on pull_request for validation and push (to main) for anything that should also run post-merge, like a deploy-adjacent job.
Use a version matrix to test against your oldest supported and newest available runtime versions, not just whichever version you develop with locally.

Developer Notes

The matrix variable name (`node-version` vs `python-version`) is chosen based on the setup type, matching the input name each respective official setup action (`actions/setup-node`, `actions/setup-python`) expects for its `with:` block; when no setup type is selected, enabling the matrix still works but the run command itself won't have a corresponding matrixed setup step.

GitHub Actions Workflow Generator Use Cases

Adding CI to a new GitHub repository from scratch
Introducing a Node or Python version matrix to an existing single-version workflow
Tightening default GITHUB_TOKEN permissions on an existing workflow

Common Mistakes

Enabling a matrix strategy but forgetting to reference `${{ matrix.* }}` in the setup step, so every matrix entry actually runs the exact same fixed version.
Leaving permissions unset entirely on a workflow that doesn't need write access, unnecessarily granting the GITHUB_TOKEN broader default permissions than the job requires.

Tips

Add a separate job with `contents: write` permissions (rather than raising the whole workflow's permissions) if only one specific step, like creating a release, needs elevated access.

GitHub Actions Workflow Generator