Principle:Triton inference server Server Repository Cloning
| Field | Value |
|---|---|
| Page Type | Principle |
| Title | Repository_Cloning |
| Namespace | Triton_inference_server_Server |
| Workflow | Custom_Container_Build |
| Domains | Version_Control, Container_Build |
| Knowledge Sources | Triton Server |
| Last Updated | 2026-02-13 17:00 GMT |
Overview
Process of acquiring specific versioned source code from a remote repository for building custom software.
Description
Building from source requires cloning the correct branch of the server repository. Release branches (r<YY.MM>) provide stable tested code while the main branch offers latest development features. Branch selection determines the Triton version and compatible backend versions.
The Triton Inference Server repository follows a release branching model where each monthly release is tagged with a branch named r<YY.MM> (e.g., r24.12 for the December 2024 release). These release branches are frozen after release and only receive critical fixes. The main branch contains the latest development code and may include untested or incomplete features.
Key considerations for branch selection:
- Release branches (
r<YY.MM>) are recommended for production builds. They are tested against specific versions of CUDA, cuDNN, TensorRT, and each backend. Version compatibility is guaranteed within a release. - Main branch is suitable for development builds where the latest features are needed. However, it may contain breaking changes or require specific dependency versions not yet documented.
- Backend version alignment is critical: each Triton release expects backends at the same release tag. Mixing release versions across server and backends can cause ABI incompatibilities or runtime failures.
Usage
Repository cloning is the second step in the Custom Container Build workflow, performed immediately after build requirements planning and before invoking either the compose or source build path.
Typical scenarios:
- Production build: Clone a specific release branch matching the desired Triton version
- Development build: Clone the main branch to access latest features
- Reproducible build: Clone a specific commit hash for exact reproducibility
- Patch build: Clone a release branch, then cherry-pick specific fixes
Theoretical Basis
The principle follows a version-pinned source acquisition pattern:
- Branch selection -- Choose the target version based on deployment requirements and backend compatibility
- Clone -- Acquire the full repository at the selected branch point
- Verified codebase -- The resulting local clone provides a reproducible starting point for the build
This pattern ensures that:
- The build inputs are deterministic and traceable to a specific point in the version history
- All build scripts (
build.py,compose.py), configuration files (CMakeLists.txt), and source code are version-consistent - The
TRITON_VERSIONfile in the repository root provides the canonical version string for the build