CI/CD for models and services with GitHub Actions

Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.

Concept: GitHub Actions · also covers CI/CD, Software development lifecycle, Automation · Step 17 of 35 in MLOps / ML platform engineer · version 1

CI/CD for machine learning extends ordinary software delivery with two extra artifacts, data and models, and a third loop, continuous training. GitHub Actions is a common engine for it: workflows defined as YAML in the repository react to events, run jobs on runners, and call out to training, evaluation, registry and deployment systems. The platform engineer's job is to design the pipeline shape and the reusable building blocks that every model team shares.

How it is done in practice

A platform team publishes a small set of reusable workflows: one that builds and scans an image and outputs its digest, one that submits a training pipeline, one that runs the evaluation gate against a registry version, and one that promotes a version by opening a pull request on the deployment repository. Model teams call these from a short workflow in their own repository and supply only parameters. Production promotion sits behind a protected environment with required reviewers, deploy jobs use a concurrency group per environment, and all cloud access goes through short-lived federated roles. Long-running work is delegated to the orchestrator, with the workflow recording run links and identifiers in the job summary.

Technologies

Diagram

flowchart LR
  A[Pull request] --> B[Lint, unit tests, smoke train]
  B --> C[Merge to main]
  C --> D[Build and push images by digest]
  D --> E[Submit training pipeline]
  E --> F[Register model version]
  F --> G[Evaluation gate job]
  G --> H{Passed?}
  H -- yes --> I[Approval on production environment]
  I --> J[PR to deployment repo]
  H -- no --> K[Fail and notify]

flowchart LR
  A[Pull request] --> B[Lint, unit tests, smoke train]
  B --> C[Merge to main]
  C --> D[Build and push images by digest]
  D --> E[Submit training pipeline]
  E --> F[Register model version]
  F --> G[Evaluation gate job]
  G --> H{Passed?}
  H -- yes --> I[Approval on production environment]
  I --> J[PR to deployment repo]
  H -- no --> K[Fail and notify]

Code

name: model-release
on:
  workflow_dispatch:
    inputs:
      model_version: {required: true, type: string}
permissions: {id-token: write, contents: read}
concurrency: release-fraud-scorer
jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: {python-version: "3.12"}
      - run: pip install -r requirements-eval.txt
      - run: python eval/gate.py --model fraud-scorer --version ${{ inputs.model_version }}
  promote:
    needs: gate
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: python release/promote.py --version ${{ inputs.model_version }}

Subtopics

Workflow anatomy

Events, jobs, steps and runners

A workflow is a YAML file under the repository's workflows directory. The on key names triggering events such as push, pull_request, schedule or workflow_dispatch. Jobs run in parallel by default on a runner chosen by runs-on, and are ordered with needs. Each job is a list of steps that either run shell commands or use a packaged action. For platform work the important features are reusable workflows invoked through workflow_call, matrix strategies, concurrency groups that prevent overlapping deploys, and job outputs that pass an image digest or model version to later jobs.

CI, CD and continuous training for ML

Three loops and maturity levels

In an ML system, CI tests and validates not only code but also data schemas and models; CD delivers a training pipeline that in turn delivers a prediction service; and continuous training automatically retrains and serves models when triggered by new data, a schedule or detected performance decay. A widely used maturity model describes three levels. At level 0 everything is manual and script driven, with rare releases. At level 1 the training pipeline is automated so models retrain continuously, with data validation and model validation as pipeline steps. At level 2 the pipeline itself has automated CI/CD, so changes to pipeline components are built, tested and deployed quickly and reliably.

What triggers what

A code change triggers CI on the pipeline code and images. A data or schedule trigger runs the deployed training pipeline. A newly approved model version triggers the serving deployment. Keeping these triggers separate avoids retraining on every commit.

Shape of a model release pipeline

Stages from commit to promotion

A typical pipeline has a fast pull request stage: lint, unit tests for feature and preprocessing code, a tiny training smoke run on sample data, and a build of the training and serving images. After merge, images are pushed by digest and the training pipeline is submitted to the orchestrator or cluster; GitHub Actions launches and watches it but does not run long GPU training on a hosted runner. When training registers a new version, a gate job runs the evaluation suite. A passing version is promoted, and the deployment job opens a change against the environment configuration or calls the serving platform, which then performs the staged rollout. Each stage hands the next one explicit identifiers: commit, image digest, model version.

Runners, credentials and protected environments

Securing and scaling the pipeline

Hosted runners suit linting, tests and image builds. Jobs that need GPUs, private network access or large caches run on self-hosted runners, commonly autoscaled on Kubernetes, and these must be isolated from untrusted pull requests. Cloud credentials should be short lived: the workflow requests an identity token and exchanges it for a cloud role scoped to that repository and branch, so no long-lived keys sit in secrets. Environments model deployment targets such as staging and production; they hold environment-scoped secrets and protection rules such as required reviewers, which gives a manual approval step before production. The permissions key should restrict the default token to the minimum, and third-party actions should be pinned to a commit.

Sources

• docWorkflow syntax for GitHub Actions (docs.github.com)
• docUnderstanding GitHub Actions (docs.github.com)
• guideMLOps: Continuous delivery and automation pipelines in machine learning (docs.cloud.google.com)

Related lessons

• Model evaluation: regression suites and release gates
• Model registry, packaging and versioning
• Reproducible environments: GitOps with Argo CD and infrastructure as code with Terraform
• Staged rollouts: shadow, canary, champion/challenger and rollback
• MLOps and the ML lifecycle: from experiment to production system
• Security, identity and access, and compliance for ML platforms
• Self-service platforms: golden paths, templates and developer tooling