Principle:Langchain ai Langgraph Release Automation
| Knowledge Sources | |
|---|---|
| Domains | CI_CD, Deployment, Automation |
| Last Updated | 2026-02-11 15:00 GMT |
Overview
Release Automation is the principle of using a fully automated, multi-stage CI/CD pipeline to build, validate, and publish LangGraph packages with minimal manual intervention and maximum safety guarantees.
Description
The LangGraph monorepo contains multiple Python packages that must be independently releasable (`langgraph`, `langgraph-checkpoint`, `langgraph-checkpoint-postgres`, `langgraph-checkpoint-sqlite`, `langgraph-sdk`, `langgraph-cli`, `langgraph-prebuilt`). Release Automation provides a single, parameterized GitHub Actions workflow that handles the complete release lifecycle for any of these packages.
The workflow is triggered manually via `workflow_dispatch`, accepting a `working-directory` parameter that identifies the target library. It proceeds through five sequential stages: build (package compilation and version extraction), release notes (changelog generation from git history), test PyPI publish (staging release via OIDC trusted publishing), pre-release checks (install from Test PyPI and run the full test suite against the published artifact), and production publish (promote to PyPI and create a GitHub release with tag and changelog).
This staged approach ensures that every release artifact is validated end-to-end before reaching production. The test suite runs against the actual published package rather than the local source, catching issues such as missing dependency declarations or packaging errors that local testing would miss.
Usage
Use Release Automation when publishing any LangGraph Python package:
- Navigate to the GitHub Actions UI and trigger the "release" workflow.
- Specify the target library via the `working-directory` input (e.g., `libs/checkpoint-postgres`).
- The pipeline handles building, testing, staging, validation, and production publishing automatically.
- Tag naming follows the convention `VERSION` for the main package and `SHORT_PKG_NAME==VERSION` for sub-packages.
Theoretical Basis
Release Automation is founded on established CI/CD security and reliability principles:
1. Separation of build and publish: The build stage has no publishing permissions, and the publish stage only receives pre-built artifacts. This limits the blast radius of compromised build steps and ensures that the same artifact is tested and published.
2. Trusted publishing (OIDC): Instead of storing long-lived API tokens as repository secrets, the workflow uses PyPI's OIDC-based trusted publishing. GitHub Actions issues short-lived identity tokens that PyPI validates, eliminating the risk of token leakage.
3. Staged validation: Publishing first to Test PyPI and then installing and testing from Test PyPI (with caching deliberately disabled) catches packaging errors, missing dependencies, and import failures before the artifact reaches production PyPI. This "test in production-like conditions" approach is more rigorous than running tests against local source.
4. Minimal permissions: Each workflow job declares only the permissions it requires (`contents: read`, `id-token: write`, or `contents: write`), following the principle of least privilege.