CI/CD for ML
Intermediate 15 min read CI/CD for ML

GitHub Actions for ML

CI/CD from the repo you already live in

GitHub Actions gives ML teams a managed CI/CD platform in the code host: workflows for smoke tests, training triggers, and model deployment, all as versioned YAML. Compute-heavy ML still wants runners and caching done deliberately.

github actionsworkflowself-hosted runnercacheML pipeline
Prerequisites: CI for ML GitHub Actions
Before we start

What you will learn

  • Write a workflow that runs an ML smoke CI
  • Configure caching and a GPU runner for training
  • Wire a registry-deploy job to workflow events
Introduction

What is this?

GitHub Actions runs ML workflows as event-driven YAML pipelines: on push learn-and-test, on schedule retrain, on review deploy. Actions give ML teams versioned automation shared with their code — with caching and runner choice deciding whether it's fast enough to be useful.

Motivation

Why do you need it?

  • Workflows live next to the code they test, versioned in the same repo.
  • Event triggers (push, PR, schedule, workflow_dispatch) cover the ML event map.
  • The marketplace ships prebuilt ML actions (setup-python, cache, GPU deps).
  • Self-hosted runners bring GPUs without leaving the Actions model.
Think about it

Mental model

Imagine

A kitchen station with shared prep lists

Think of

GitHub Actions workflows

Triggers are the ticket under the pass (PR), schedules are dinner service (cron), and the runner is your line cook — the tools Matter more than the host. Cache is today's mis-en-place, ready before the shift.

Mechanics

How it works

  • A YAML workflow in .github/workflows declares triggers, jobs, steps.
  • On trigger, Actions provisions a runner (GitHub-hosted or self-hosted).
  • Steps restore a cached environment (deps, datasets, model caches).
  • Jobs run in dependency order across a matrix if needed.
  • Step results gate success/failure; artifacts and registry writes follow.
  • Cron schedules retraining; registry events can trigger deployment workflows.

An ML GitHub Actions workflow graph.

Trigger
Checkout + cache
CI job
Register
Deploy job
Done
Hands-on

Examples

A minimal smoke-CI workflow

A minimal smoke-CI workflow
on:
  push:
    paths: ['training/**', '.github/workflows/ci.yml']
jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: '3.11', cache: pip }
      - run: pip install -r training/requirements-smoke.txt
      - run: python training/ci_smoke.py

A repo-scoped workflow runs the smoke check on relevant pushes, caches pip, and fails the checkout loudly when CI is broken.

Real world

In production

  • A scheduled workflow retrains the churn model nightly on a self-hosted GPU runner.
  • A deployment workflow triggered by a registry event promotes the model through stages.
  • Cached datasets cut smoke CI from 12 minutes to 3 on cache hits.
Guidelines

Best practices

  • Cache dependencies and (read-only) datasets by their version hash.
  • Scope triggers to relevant paths so docs edits don't burn GPU.
  • Keep CI workflows on GitHub-hosted runners; training on self-hosted GPU.
  • Upload test artifacts and scores so failures are diagnosable after the run ends.
Watch out

Common mistakes

  • Training on GitHub-hosted runners with no GPU and wondering why it's slow.
  • Cache-invalidating every run anyway (no hash key) — the cache is theater.
  • Marking infrastructure retries as failures when the job is genuinely flaky.
  • Secrets pasted into workflow YAML instead of GitHub secrets.
When things break

Debugging tips

  • Workflow 'passes but trained nothing' — check whether the train step actually ran or skipped on an event filter.
  • Cache misses repeatedly — compare cache keys; the hash may include volatile files.
  • Self-hosted runner offline — look at runner registration/version before blaming the YAML.
Interviews

Interview checkpoint

Practice

Hands-on lab

Wire an ML CI Workflow
40 min · intermediate
In progress
Objectives
  • Author a YAML workflow with triggers and jobs
  • Add caching and a seeded smoke train
  • Emit an artifact diff for review

Wire an ML CI Workflow

40 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

What makes Actions ML pipelines fast enough to be CI?

2

Training jobs over an hour belong on a GPU runner, not a default GitHub-hosted runner.

Go deeper

Official documentation

GitHub Actions documentation
docs