GitHub Actions Workflow Generator

About this tool

GitHub Actions Workflow Generator on UtilityKit creates ready-to-use YAML workflow files for common CI/CD patterns — CI test runs, Docker image builds and pushes, automated deployments, and pull-request checks — without requiring you to memorise the GitHub Actions YAML schema. Select your trigger events (push, pull_request, schedule, workflow_dispatch), pick one or more job templates (lint, test, build, deploy), configure your runtime environment, and the generator assembles a syntactically valid `.github/workflows/` file you can drop into your repository. Each generated workflow follows GitHub's official recommendations: pinned action versions, explicit permissions blocks, concurrency groups to cancel redundant runs, and secret references rather than hard-coded credentials. Ideal for teams setting up CI for the first time and engineers who want a correct scaffold without wading.

Why use it

• Schema-Correct YAML: The generator produces syntactically valid workflow YAML that passes GitHub's schema validation on the first push, eliminating the red-X loop of fixing indentation errors.

• Pinned Action Versions: All `uses:` references include the recommended version pin (e.g. `actions/checkout@v4`) so your workflow does not silently break when an action publishes a breaking change.

• Security Hardened: Generated workflows include explicit `permissions:` blocks scoped to minimum required access, and reference secrets by name rather than embedding credentials.

• Concurrency Groups: Automatic concurrency group configuration cancels in-progress runs on the same branch when a new push arrives, saving CI minutes on fast-moving branches.

• Multiple Trigger Types: Supports push, pull_request, schedule (cron), and workflow_dispatch triggers — mix and match for complex CI/CD pipelines without hand-writing every trigger block.

• No Account or CLI Required: Runs entirely in your browser. No GitHub login, no CLI tools, and no Actions billing required to generate, copy, and inspect workflows.

How to use

1. Choose your workflow trigger events: push to main, pull_request targeting main, manual workflow_dispatch, or a cron schedule.
2. Select the job templates you need: Lint (ESLint / flake8), Test (unit tests with coverage), Build (Docker image), or Deploy (SSH / cloud provider).
3. Set your runner OS — ubuntu-latest is the default; macOS and Windows runners are also available for cross-platform projects.
4. Configure environment details: Node/Python/Go version matrix, package manager cache strategy, and any required secrets by name.
5. Toggle optional features: concurrency group (cancel in-progress runs on new push), artifact upload (test reports, build artefacts), and status badges.
6. Click Generate Workflow, then copy the YAML or download it. Save the file as `.github/workflows/<name>.yml` in your repository and push it.

When it helps

• When setting up CI for a new repository and you want a test-and-lint workflow without reading the entire GitHub Actions documentation.
• When adding automated Docker builds and pushes to GHCR or Docker Hub for the first time and need the correct `docker/login-action` and `docker/build-push-action` sequence.
• When you want a pull-request check that blocks merges unless tests pass, and need the correct `pull_request` trigger with branch filters.
• When migrating a project from CircleCI or Jenkins and need an equivalent GitHub Actions YAML to compare and adapt.
• When teaching a team how GitHub Actions works and you need a commented, readable example to walk through step by step.
• When you need a scheduled nightly job (cron trigger) to run integration tests or dependency audits without writing cron syntax from memory.

Examples

Trigger: push + pull_request, Job: Test, Runtime: Node 20, Cache: npm

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

Trigger: push to main, Job: Build + Push, Registry: ghcr.io

name: Docker
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:latest

Trigger: cron 02:00 UTC daily, Job: Audit, Runtime: Node 20

name: Nightly Audit
on:
  schedule:
    - cron: '0 2 * * *'
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npm audit --audit-level=high

Tips

• Use `workflow_dispatch` as a second trigger alongside `push` so you can re-run the workflow manually from the GitHub UI without pushing a dummy commit — invaluable for debugging flaky tests.
• Cache your dependency install step with `actions/cache` or the built-in cache option in `actions/setup-node`. A warm cache turns a 90-second `npm ci` into a 5-second restore.
• Set `continue-on-error: true` on linting steps in PRs so lint failures are visible but do not block the more important test results from completing.
• Use environment protection rules in GitHub repository settings to gate deploy jobs behind a manual approval step — this prevents accidental production deploys on every merge.
• Prefix test-and-build workflow names with an emoji status (e.g. `🧪 CI`) to make the checks panel easier to scan at a glance in pull-request status summaries.

Frequently Asked Questions

Glossary

Workflow

A configurable automated process defined in a YAML file under `.github/workflows/`. A workflow contains one or more jobs triggered by repository events.

Job

A set of steps that run on the same runner in a workflow. Jobs run in parallel by default; use `needs:` to sequence them.

Runner

The virtual machine or container that executes a job. GitHub provides hosted runners (ubuntu-latest, windows-latest, macos-latest) or you can register your own self-hosted runners.

GITHUB_TOKEN

An automatically generated short-lived token provided to every workflow run, scoped to the repository. Used to push packages, comment on PRs, and create releases without storing a personal access token.

Concurrency group

A named slot that limits simultaneous workflow runs. When a new run starts with the same group key, the in-progress run is cancelled, preventing redundant CI work.

Matrix strategy

A workflow feature that fans out a single job across multiple parameter combinations (e.g. OS × runtime version) and runs them in parallel, providing broad compatibility coverage efficiently.