GitHub Actions Workflow Generator

You need a CI pipeline that runs tests on push, builds a Docker image on merge to main, and publishes to GitHub Container Registry with a version tag. That’s three jobs with needs: dependencies, environment secrets for the registry, a matrix strategy for Node 18 and 20, and caching for node_modules. The YAML indentation alone takes 10 minutes to get right, and a single misplaced uses: vs run: breaks the entire workflow.

Why This Generator (Not Starter Workflows or Copy-Paste)

GitHub’s starter workflows cover the basics but you still spend 20 minutes customizing them — adding caching, matrix builds, environment variables, and deploy steps. Copy-pasting from other repos means inheriting their specific versions and assumptions. This tool lets you configure triggers, jobs, steps, and environment variables through a form and generates the complete YAML with live preview. Everything runs in your browser; your workflow configuration never leaves your device.

What Is GitHub Actions?

GitHub Actions is GitHub’s built-in CI/CD (Continuous Integration / Continuous Delivery) platform. It lets you automate software workflows — running tests, building containers, deploying apps, and publishing packages — directly inside your GitHub repository. Workflows are defined as YAML files stored in .github/workflows/.

A workflow consists of:

• Triggers (on:) — events that start the workflow (push, pull request, schedule, manual)
• Jobs — groups of steps that run on a runner machine (e.g., ubuntu-latest)
• Steps — individual tasks: run a shell command (run:) or execute a reusable action (uses:)
• Environment variables — key-value pairs accessible across all jobs

How to Use This Generator

1. Choose a preset — pick the workflow type that matches your project (Node.js CI, Python CI, Docker build+push, etc.) to load a pre-configured starting point
2. Configure triggers — check which events should start your workflow: push, pull_request, schedule, workflow_dispatch, or release
3. Edit jobs and steps — customize runner OS, add or remove steps, configure uses: actions or run: shell commands
4. Set environment variables — add global env: key-value pairs that are available to all jobs
5. Copy the YAML — click Copy to copy the generated workflow YAML, then save it as .github/workflows/your-workflow.yml in your repository

Supported Presets

Node.js CI

The Node.js CI preset sets up a complete continuous integration pipeline:

• Triggers on push to main/develop and on pull requests
• Uses actions/setup-node@v4 with npm caching
• Runs npm ci, npm run lint, npm test, and npm run build

Customise the Node.js version, add a coverage step, or change the branch names as needed.

Python CI

The Python CI preset provides a standard Python testing workflow:

• Uses actions/setup-python@v5 with pip caching
• Installs dependencies from requirements.txt
• Lints with flake8 for syntax errors and undefined names
• Runs pytest for test execution

Adjust the Python version (e.g., 3.11, 3.12) or swap flake8 for ruff to match your project.

CI (test + build)

A language-agnostic CI template with placeholder test and build steps. Start here if your stack isn’t covered by another preset, then fill in your own commands.

CD (deploy)

A deployment workflow triggered on push to main. Includes a concurrency group that automatically cancels in-progress deploys when a newer push arrives. Add your deploy command (SSH, rsync, AWS CLI, etc.) to the deploy step.

Docker build + push

Builds a Docker image and pushes it to Docker Hub using the official docker/build-push-action:

• Uses docker/login-action@v3 for authentication
• docker/metadata-action@v5 generates image tags from Git refs and semver tags
• Builds and pushes on push to main; only builds (no push) on pull requests
• Requires DOCKERHUB_USERNAME and DOCKERHUB_TOKEN secrets in your repository

Replace your-dockerhub-username/your-image-name with your actual image name, or change the registry to GHCR (ghcr.io/owner/repo).

Release / publish

Publishes a package to the npm registry whenever you create a GitHub Release:

• Triggered by the release: published event
• Sets up Node.js with the npm registry URL configured
• Runs npm run build then npm publish
• Requires the NPM_TOKEN secret

Workflow Triggers Explained

Cron Syntax for Schedule Triggers

GitHub Actions uses standard 5-field UTC cron syntax:

┌─────────── minute (0–59)
│ ┌───────── hour (0–23, UTC)
│ │ ┌─────── day of month (1–31)
│ │ │ ┌───── month (1–12)
│ │ │ │ ┌─── day of week (0–6, 0=Sunday)
│ │ │ │ │
0 2 * * *   # every day at 2:00 AM UTC
0 */6 * * * # every 6 hours
0 9 * * 1   # every Monday at 9:00 AM UTC

Note: GitHub Actions does not guarantee exact execution time for scheduled workflows. They can run up to 15 minutes late during heavy load periods.

Best Practices

Security:

• Store sensitive values (API keys, tokens, passwords) in GitHub Secrets (Settings → Secrets and variables → Actions). Reference them as ${{ secrets.MY_SECRET }} — never hard-code credentials in YAML files.
• Pin third-party actions to a full commit SHA (e.g., actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683) in security-sensitive workflows to prevent supply-chain attacks. Version tags like @v4 are convenient but can be overwritten.

Performance:

• Use actions/cache (or built-in cache parameter in setup-node, setup-python) to cache dependencies and speed up workflows.
• Split long workflows into multiple jobs that run in parallel using the needs: field for sequencing.
• Use concurrency groups with cancel-in-progress: true for deployment workflows to avoid redundant deploys.

Reliability:

• Set timeout-minutes on jobs to prevent hung workflows from consuming minutes indefinitely.
• Use strategy.matrix to test across multiple Node.js versions, OS combinations, or Python versions in a single workflow file.
• Add if: conditions to skip unnecessary steps (e.g., skip lint on schedule triggers).

Common GitHub Actions Patterns

Run only on main branch push:

if: github.ref == 'refs/heads/main'

Skip CI for docs-only changes:

push:
  paths-ignore:
    - '**.md'
    - 'docs/**'

Matrix build across Node.js versions:

strategy:
  matrix:
    node-version: ['18', '20', '22']
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: ${{ matrix.node-version }}

Reuse workflow output between jobs:

jobs:
  build:
    outputs:
      artifact-path: ${{ steps.build.outputs.path }}
  deploy:
    needs: build
    steps:
      - run: echo "${{ needs.build.outputs.artifact-path }}"

Frequently Asked Questions

Where do I put the generated YAML file? Save it as any .yml or .yaml file inside .github/workflows/ in your repository root. For example: .github/workflows/ci.yml. GitHub automatically detects and runs all workflow files in this directory.

What are GitHub Actions minutes? GitHub provides free monthly minutes for Actions on public repositories (unlimited) and private repositories (2,000 free minutes/month on the Free plan). Linux runners consume 1× minutes, Windows 2×, and macOS 10×.

How do I access my repository secrets in a workflow? Use the ${{ secrets.SECRET_NAME }} expression syntax. Secrets are masked in logs. Set them in your repository under Settings → Secrets and variables → Actions.

Can I run a workflow manually? Yes. Enable the workflow_dispatch trigger. A “Run workflow” button will appear in the Actions tab of your repository. You can also trigger it via the GitHub API or CLI (gh workflow run).

What is the difference between uses: and run: in a step? uses: runs a pre-built action from the GitHub Actions Marketplace (e.g., actions/checkout@v4). run: executes a shell command directly on the runner. You can use both in the same job but not in the same step.

Is my data sent to a server? No. All YAML generation happens entirely in your browser. No workflow configurations, secrets, or code are sent to any server.