Made With ML - Moses Yebei

The Problem

Teams that want to turn a Jupyter prototype into a reproducible, production‑grade ML service often lack a single, opinionated code base that demonstrates end‑to‑end data loading, training, tuning, evaluation, and serving while also exposing a CI pipeline and Kubernetes deployment. Maintaining consistency across notebooks, Python modules, and YAML manifests is error‑prone without a clear wiring diagram.

What This Does

The repository bundles a minimal ML product line in the madewithml/ package. Core responsibilities are split across a handful of files:

madewithml/data.py – loads CSV datasets, performs text cleaning (clean_text) and stratified splitting.
madewithml/train.py & madewithml/tune.py – implement a training loop (train_model) and hyper‑parameter sweep (tune_models).
madewithml/predict.py – wraps a PyTorch model with predict_proba, decode, and format_prob.
madewithml/serve.py – provides the entry points _evaluate and _predict for a FastAPI‑style service.

Documentation lives under docs/ and example notebooks in notebooks/. CI is defined in .github/workflows/ and deployment manifests for a Kubernetes cluster are in deploy/.

How It Is Wired

Execution starts in madewithml/serve.py:

_evaluate (line 49) calls evaluate() (from madewithml/evaluate.py).
evaluate() pulls a preprocessor via get_preprocessor(), transforms data (transform()), and finally writes results with save_dict() (calls os.makedirs → filesystem).

The other entry point, _predict (line 55), follows:

Calls madewithml/predict.__call__, which invokes predict_proba.
predict_proba routes through collate_fn → pad_array, then through the model’s forward (in madewithml/models.py) and finally formats probabilities with format_prob.

The internal call graph shows 25 modules, 28 import edges and no circular dependencies. The most connected hub is madewithml/__init__ (imported by 11 other modules). Functions with the widest blast radius include transform (called from 7 places) and from_checkpoint (5 places).

External interactions are limited to:

File I/O (save_dict, load_dict) – 2 functions.
One outbound network call (presumably a model‑registry fetch).
One external command execution (via subprocess in the deployment scripts).

No database writes are present in the core library; the only persistence is filesystem‑based checkpoint storage.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/Made-With-ML
cd Made-With-ML

# Install dependencies (pyproject.toml defines runtime, requirements.txt pins exact versions)
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt   # or: pip install .

# Run the unit test suite (CI currently lacks a test step, but tests exist)
pytest tests/code

# Start the service locally (entry point)
python -m madewithml.serve   # invokes _predict/_evaluate via the server code

Configuration lives in madewithml/config.py; adjust paths or model hyper‑parameters there before training. Deploy to Kubernetes with the manifests in deploy/ (e.g., kubectl apply -f deploy/services/serve_model.yaml).

Real‑World Use

A data‑science team can iterate on a text classification model by:

from madewithml.train import train_model
from madewithml.tune import tune_models

# Train a baseline
train_model(num_epochs=5, batch_size=32)

# Run a hyper‑parameter sweep
tune_models(search_space={"lr": [1e-4, 1e-3], "batch_size": [16, 32]})

After validation, the same madewithml/serve.py module is packaged into a Docker image and deployed with the provided Helm‑style YAML, ensuring the production service uses identical code to the notebook experiments.

Code Health & Issues

Critical – .github/workflows/serve.yaml grants permissions: write-all.
High – GitHub Actions are not pinned to commit SHAs; no lockfile beside pyproject.toml; CI workflow never runs tests; missing least‑privilege token declarations.
Medium – deploy/services/serve_model.py opens files without a context manager; duplicated logic in train.py/tune.py; deep nesting and high branching in .github/workflows/json_to_md.py; lack of Dependabot; missing job timeouts; notebook outputs not stripped; checkout persists credentials.
Low – No job timeout set in documentation.yaml.

All findings are derived from static analysis; no additional issues were inferred beyond the repository contents.

The Bottom Line

The repo offers a coherent, end‑to‑end ML pipeline with clear module boundaries and reproducible notebooks, making it a solid learning and starter kit. However, production readiness is hampered by several CI and security misconfigurations and a few code‑quality smells that should be addressed before commercial deployment. It is best suited for teams that need a reference implementation and are prepared to tighten the CI/security posture.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

56 files

Python25
Markdown10
YAML9
Jupyter Notebook2
Shell1
TOML1

Kubernetes

Module dependencies

The 10 most depended-upon modules of 25, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_madewithml___init__["__init__"] n1_madewithml_config["config"] n2_madewithml_predict["predict"] n3_madewithml_data["data"] n4_madewithml_models["models"] n5_madewithml_serve["serve"] n6_madewithml_utils["utils"] n7_madewithml_evaluate["evaluate"] n8_madewithml_train["train"] n9_deploy_services_serve_model["serve_model"] n9_deploy_services_serve_model --> n1_madewithml_config n9_deploy_services_serve_model --> n5_madewithml_serve n3_madewithml_data --> n1_madewithml_config n7_madewithml_evaluate --> n0_madewithml___init__ n7_madewithml_evaluate --> n1_madewithml_config n7_madewithml_evaluate --> n2_madewithml_predict n2_madewithml_predict --> n1_madewithml_config n2_madewithml_predict --> n3_madewithml_data n2_madewithml_predict --> n4_madewithml_models n2_madewithml_predict --> n6_madewithml_utils n5_madewithml_serve --> n0_madewithml___init__ n5_madewithml_serve --> n1_madewithml_config n8_madewithml_train --> n0_madewithml___init__ n8_madewithml_train --> n1_madewithml_config n8_madewithml_train --> n4_madewithml_models n6_madewithml_utils --> n1_madewithml_config

Findings

LowDependencies declared without a lockfile - non-reproducible builds pyproject.toml

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high3

medium5

low1

Replace write-all with the scopes the job actually needscritical

.github/workflows/serve.yaml

permissions: write-all

One malicious step gets simultaneous write to code, packages, releases, deployments and Actions itself.

Fix: Enumerate only the scopes each job uses and default the workflow to contents: read.

Pin third-party GitHub Actions to a commit SHAhigh2 occurrences

.github/workflows

aws-actions/configure-aws-credentials@v2, thollander/actions-comment-pull-request@v2

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Make CI invoke the test suite it hashigh12 occurrences

.github/workflows

12 test files, no test command in any workflow

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/documentation.yaml

1 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Strip notebook outputs before committingmedium

notebooks/madewithml.ipynb

1 notebook(s) over 1MB, 2.4MB total, dominated by stored output

Outputs are where a printed dataframe of customer rows or a traceback containing a connection string ends up, and diff review never reads them.

Fix: Install nbstripout and clear the existing outputs once.

Set persist-credentials: false on checkoutmedium

.github/workflows/documentation.yaml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/documentation.yaml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.