Where does this workflow file go?

Save it as .github/workflows/ci.yml in your repository root. GitHub runs any workflow under .github/workflows automatically on the configured events, here push and pull_request to your chosen branch.

What does the flake8 step check?

It runs flake8 twice: the first pass with --select=E9,F63,F7,F82 catches genuine errors like syntax errors and undefined names and fails the build, while the second pass reports style issues up to a line length you set without failing. This is the pattern GitHub recommends in its Python starter workflow.

How does pip caching speed things up?

The setup-python action with cache: pip caches the pip download directory keyed on your requirements file. On later runs, pip installs from the warm cache instead of downloading every wheel again, which noticeably shortens the install step.

What happens to the coverage report?

pytest runs with --cov to produce a coverage.xml, and the workflow uploads it as a build artifact named per Python version. You can download it from the run, or swap the upload step for a coverage service action like codecov to track coverage over time.

When should I enable the Docker build job?

Enable it if your project ships as a container. The docker job sets needs: test so it only runs after the test matrix passes, then builds the image tagged with the commit SHA, which verifies your Dockerfile stays buildable on every change.

GitHub Actions CI Workflow Builder (Python)

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

A GitHub Actions CI workflow builder for Python that generates a valid .github/workflows/ci.yml. Choose the Python versions to test, whether to lint with flake8, whether to collect coverage, and whether to add a Docker build, and it produces a matrix workflow with pip caching.

How it works

The test job runs on ubuntu-latest with a strategy.matrix.python-version listing your versions as quoted strings (so 3.10 is not parsed as the number 3.1). fail-fast: false runs every version even when one fails. Each run checks out the code, sets up Python with actions/setup-python@v5 and cache: pip, then installs requirements.txt plus pytest and the optional tooling.

When lint is on, it runs the two-pass flake8 pattern: a strict pass that fails on real errors (E9,F63,F7,F82) and a permissive style pass. When coverage is on, pytest runs with --cov and the resulting coverage.xml is uploaded as a per-version artifact. An optional second docker job, gated by needs: test, builds your image tagged with the commit SHA only after the matrix passes.

Tips and notes

Python versions are emitted as quoted strings on purpose — an unquoted 3.10 would be read as the float 3.1 by YAML, silently testing the wrong runtime.
Keep a requirements.txt (or adjust the install step for pyproject.toml / requirements-dev.txt); the workflow installs from it before running tests.
Replace the coverage upload with the codecov/codecov-action step if you want coverage trends and PR comments rather than a downloadable artifact.
The strict flake8 pass is the one that should gate merges — it flags undefined names and syntax errors that would crash at runtime, independent of style preferences.