elefcode

GitHub Actions Workflow Generator

Pick a stack, triggers and steps, and get a ready CI workflow — Node, Python, Go or Docker image builds.

Project
Package manager
Operating systems
Steps
Triggers
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: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        version: ['22', '24']
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: ${{ matrix.version }}
          cache: npm
      - name: Install dependencies
        run: npm ci
      - name: Lint
        run: npm run lint
      - name: Test
        run: npm run test
      - name: Build
        run: npm run build
  • Save as .github/workflows/ci.yml. For stricter supply-chain security, pin third-party actions to a full commit SHA.

Advertisement

Guide

About the GitHub Actions Workflow Generator

GitHub Actions runs workflows defined in YAML files under .github/workflows/. Each workflow lists the events that start it, and one or more jobs made of steps: check out the code, set up a language runtime, install dependencies and run your commands.

Choose your stack and the generator writes a workflow with current action versions, read-only permissions by default, and caching keyed on your lockfile.

Matrix builds

Listing several versions or operating systems turns the job into a matrix: GitHub runs one copy per combination in parallel. fail-fast: false lets the others finish when one fails, so you see every broken combination in a single run.

Least-privilege tokens

Every run gets a GITHUB_TOKEN. The workflow sets permissions: contents: read so a compromised step cannot push code, and the Docker job adds only packages: write, which it needs to publish to GHCR.

How to use it

  1. 1Choose Node.js, Python, Go or a Docker image build.
  2. 2Set versions, operating systems and the commands to run.
  3. 3Pick when the workflow should run.
  4. 4Save the YAML in .github/workflows/ and push.

Frequently asked questions

Where do I put the workflow file?

In .github/workflows/ at the root of the repository, with a .yml or .yaml extension. GitHub picks it up on the next push.

How do I push Docker images to GitHub Container Registry?

Choose Docker image and GitHub Container Registry. The workflow logs in with the built-in GITHUB_TOKEN, so no extra secret is needed, and it is granted packages: write.

Why are pull requests built but not pushed?

Pull requests from forks should not be able to publish images. The workflow builds them to check the Dockerfile works, and pushes only for branch and tag events.

What time zone does the schedule use?

UTC. Scheduled runs can start a few minutes late when GitHub is busy, and they stop after 60 days without repository activity on public repos.

How does dependency caching work?

setup-node, setup-python and setup-go save the package cache after a run and restore it next time, keyed on a hash of your lockfile. A changed lockfile starts a fresh cache.

Should I pin actions to a SHA?

Tags like @v5 can be moved by the action’s owner. Pinning to a full commit SHA guarantees the exact code that runs; Dependabot can keep pinned SHAs up to date.

Related tools

Dockerfile GeneratorCron GeneratorYAML ↔ JSON.gitignore Generator