Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:Langchain ai Langchain CI Configuration

From Leeroopedia

Template:Metadata

Overview

A CI strategy that automatically detects which partner packages are affected by a code change and runs only the necessary test, lint, and build workflows.

Description

The CI Configuration principle describes how the LangChain monorepo's continuous integration system efficiently determines which packages need testing based on the files changed in a pull request. Rather than running all tests for all packages on every change, the CI uses a diff-analysis script to build a targeted test matrix.

Key design elements:

  • Change detection: A Python script (check_diff.py) analyzes the list of changed files from a git diff and maps each file to its owning package directory.
  • Dependency graph: The script builds a dependency graph by parsing pyproject.toml files across the monorepo. When a core package changes, all packages that depend on it are also scheduled for testing.
  • Job categorization: Changed files are mapped to four job categories:
    • lint: Linting and formatting checks
    • test: Unit tests
    • extended-test: Extended test suites for core packages
    • codspeed: Performance benchmarks
  • Test matrix generation: The script outputs JSON configurations for GitHub Actions matrix strategies, specifying the working directory and Python version for each test job.
  • Python version coverage: Core packages are tested across Python 3.10-3.14. Partner packages are tested on Python 3.10 and 3.14. Performance benchmarks run on Python 3.13.
  • Pydantic compatibility: A dedicated test-pydantic job tests across multiple Pydantic 2.x minor versions to ensure compatibility.
  • Safety measures: Changes to CI infrastructure files (.github/workflows, .github/scripts) trigger tests on all core packages as a conservative safety measure.

Benefits:

  • Fast CI on small changes (only affected packages are tested).
  • Complete coverage on foundational changes (core changes propagate to dependents).
  • Automatic discovery of new partner packages without manual CI configuration.

Usage

Apply this principle when:

  • Adding a new partner package and expecting it to be automatically discovered by CI.
  • Modifying CI workflows and understanding the blast radius of changes.
  • Debugging why a particular package's tests were or were not triggered by a PR.

Theoretical Basis

The approach implements a build-graph-based incremental CI strategy. By analyzing the dependency graph at runtime rather than hardcoding package relationships, the system adapts automatically as packages are added or dependencies change.

1. Receive list of changed files from git diff
2. For each file:
   a. Map to owning package directory (libs/partners/<name>, libs/core, etc.)
   b. Determine job category (lint, test, extended-test, codspeed)
3. Build dependency graph from all pyproject.toml files
4. For test/lint jobs, add dependents of changed packages
5. Generate per-job test matrix with (working-directory, python-version) pairs
6. Output JSON for GitHub Actions matrix strategy

Related Pages

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment