BYTETOOLS

GitHub Actions Workflow Generator

Build a .github/workflows CI file from a form: triggers, runner OS, language version matrix, dependency caching, permissions and lint, test and build steps.

Triggers

Steps and options

.github/workflows/ci.yml

name: CI

on:
  push:
    branches:
      - "main"
  pull_request:
    branches:
      - "main"
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: ${{ matrix.os }}
    timeout-minutes: 15
    strategy:
      fail-fast: false
      matrix:
        os:
          - ubuntu-latest
        node-version:
          - "20.x"
          - "22.x"
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "${{ matrix.node-version }}"
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Test
        run: npm test

      - name: Build
        run: npm run build

Save this as .github/workflows/ci.yml in your repository. The install, lint, test and build commands are sensible defaults for each ecosystem — edit them to match the scripts your project actually defines.

What is the GitHub Actions Workflow Generator?

This generator writes a complete GitHub Actions workflow from a handful of choices. Pick your language and runner, tick the triggers you want, and it produces correctly indented YAML with pinned actions/checkout@v4 and setup-* action versions, ready to drop into .

  • Push, pull_request, schedule and workflow_dispatch triggers with branch and path filters
  • Language version matrix with fail-fast disabled so one failure does not hide the rest
  • Dependency caching wired to npm, pip or Maven via the official setup actions
  • Least-privilege permissions block and a concurrency group that cancels stale runs
  • Actions pinned to major versions such as actions/checkout@v4
  • Correct two-space YAML indentation, with multi-line scripts emitted as block scalars

How to use the GitHub Actions Workflow Generator

  1. 1

    Enter a workflow name and choose your language: Node.js, Python, Go, Java or Ruby.

  2. 2

    Pick the runner OS and list the language versions you want in the matrix.

  3. 3

    Tick the triggers you need — push, pull_request, workflow_dispatch or a cron schedule — and fill in branch, path or cron filters.

  4. 4

    Toggle the matrix, dependency caching, and the lint, test and build steps.

  5. 5

    Copy the YAML or download it and save it as .github/workflows/<name>.yml.

About the GitHub Actions Workflow Generator

This generator writes a complete GitHub Actions workflow from a handful of choices. Pick your language and runner, tick the triggers you want, and it produces correctly indented YAML with pinned actions/checkout@v4 and setup-* action versions, ready to drop into .github/workflows.

It covers the parts people usually get wrong: a version matrix with fail-fast disabled, dependency caching wired to the right package manager, a least-privilege permissions block, and a concurrency group that cancels superseded runs so pushes do not queue up behind each other.

The whole file is rebuilt in your browser every time you change the form, so nothing is sent anywhere and no repository access or GitHub sign-in is needed. You get plain YAML text to copy or download, review against your own build scripts, and commit whenever you are happy with it.

Frequently asked questions

Where do GitHub Actions workflow files go?

In a .github/workflows folder at the root of your repository, as .yml or .yaml files. GitHub picks up every workflow file in that directory automatically once you push it to the default branch.

What does the concurrency block do?

It groups runs by workflow and branch and cancels any run that a newer push supersedes. That stops a queue of redundant builds forming when you push several commits quickly, and it saves a lot of Actions minutes on busy branches.

Why set permissions to contents: read?

The default GITHUB_TOKEN can be granted broad write access. Declaring the minimum your job needs means a compromised dependency in your build cannot push code, open releases or alter issues. Add specific write scopes back only where a job genuinely requires them.

How does a build matrix work?

The matrix runs your job once per combination of the values you list — for example once for each Node version. Setting fail-fast to false lets every combination finish, so you see all the failures at once rather than only the first.

Are the generated commands right for my project?

They are ecosystem defaults, like npm ci and npm test, so check them against the scripts your project actually defines. Edit the run lines after you paste the file if your commands differ.

Why is the on: key not quoted?

Under the YAML 1.2 spec that GitHub uses, only true and false are booleans, so a bare on is an ordinary string key. That is why every workflow in GitHub's own documentation writes it unquoted.

Related tools