코드 기여하기
코드 기여하기 (Contributing Code)
PR 제출 전 체크리스트
LiteLLM에 제출되는 모든 PR의 핵심 요구사항입니다:
- Contributor License Agreement (CLA) 서명
- 범위를 최대한 격리하세요. 변경은 한 번에 하나의 특정 문제를 다뤄야 합니다
- Commit and Branch Conventions 를 따르세요. PR 제목은 CI가 게이트합니다
Proxy (백엔드) PR
- 테스트 추가. 테스트 최소 1개는 하드 요구사항입니다 (details)
- PR이 통과하는지 확인: Unit Tests:
make test-unit/ Formatting & Linting Tests:make lint
UI PR
- UI가 성공적으로 빌드되는지 확인:
npm run build - 모든 UI 유닛 테스트가 통과하는지 확인:
npm run test - 새 컴포넌트나 새 로직을 추가한다면 대응 테스트를 추가하세요
Contributor License Agreement (CLA)
LiteLLM에 코드를 기여하기 전에 Contributor License Agreement (CLA) 에 서명해야 해요. 이는 모든 기여가 main 저장소에 병합되기 위한 법적 요구사항입니다. CLA는 기여가 이뤄지는 조건을 명확히 정의함으로써 기여자와 프로젝트를 모두 보호합니다.
중요: 리뷰 과정의 지연을 피하기 위해 기여를 시작하기 전에 CLA에 서명하는 것을 강력히 권장합니다. CLA는 여기에서 찾아 서명할 수 있습니다.
Commit 및 Branch 규칙
LiteLLM은 두 가지 커뮤니티 스펙을 강제합니다:
- 커밋은 Conventional Commits 1.0.0 을 따릅니다:
<type>(<scope>)!: <description> - 브랜치는 Conventional Branches 를 따릅니다:
<type>/<description>
강제는 두 곳에서 이뤄집니다: .githooks/ 의 옵트인 로컬 git hooks, 그리고 PR 제목의 필수 CI 체크 (스쿼시 병합이 PR 제목을 커밋 주제로 사용하므로).
커밋 메시지 형식
<type>(<optional scope>)!: <description>
<optional body>
<optional footer>
<type>은 다음 중 하나:feat,fix,docs,style,refactor,perf,test,build,ci,chore,revert.<scope>는 선택이고 소문자.:앞의!는 breaking change를 표시.<description>은 필수이고 소문자로 시작해야 합니다 (숫자와 기호도 괜찮고, A-Z만 거부).
예시:
feat(router): add weighted round-robin strategy
fix(bedrock): decouple STS region from aws_region_name
chore(deps): bump ruff to 0.15.0
refactor!: drop Python 3.8 support
PR 제목도 같은 형식을 따라야 합니다. 스쿼시 병합이 PR 제목을 커밋 주제로 사용하고, Conventional PR Title 워크플로가 이를 검증하기 때문입니다.
브랜치 명명
형식: <type>/<short-description> — 여기서 <type> 은 feature, bugfix, hotfix, release, chore 중 하나.
feature/weighted-round-robin
bugfix/streaming-empty-chunks
chore/bump-ruff
hotfix/auth-bypass
release/v1.45.0
항상 허용되는 브랜치 (pre-push hook이 우회합니다):
mainlitellm_internal_stagingdependabot/*gh-readonly-queue/*
태그 푸시와 브랜치 삭제도 건너뜁니다.
hooks 설치
hooks는 .githooks/ 에 있으며 옵트인입니다. 클론당 한 번 실행하세요:
make install-hooks
이것은 로컬 저장소에 core.hooksPath=.githooks 를 설정합니다. 그 후:
git commit은 커밋 메시지 헤더를 검증하는commit-msg를 실행git push는 브랜치 이름을 검증하는pre-push를 실행
드문 비상 상황에서는 명령 하나로 두 hook을 우회할 수 있어요:
git commit --no-verify -m "..."
git push --no-verify
제거하려면: git config --unset core.hooksPath.
출처: 문서
본문
Proxy (백엔드)
1. 로컬 개발 환경 설정
1단계: 저장소 클론
git clone https://github.com/BerriAI/litellm.git
2단계: dev 의존성 설치
uv sync --group dev --extra proxy
2. 테스트 추가
tests/test_litellm/디렉터리에 테스트를 추가하세요.- 이 디렉터리는
litellm/디렉터리를 1:1로 반영하며, mocked 테스트만 포함해야 합니다. - 실제 LLM API 호출을 이 디렉터리에 추가하지 마세요.
tests/test_litellm/ 의 파일 명명 규칙
테스트 디렉터리는 litellm/ 과 같은 구조를 따릅니다:
test_{filename}.py는litellm/{filename}.py에 매핑litellm/proxy/test_caching_routes.py는litellm/proxy/caching_routes.py에 매핑
3. 유닛 테스트 실행
litellm 디렉터리 루트에서 다음 명령을 실행하세요:
make test-unit
4. 린트 테스트 실행
litellm 디렉터리 루트에서 다음 명령을 실행하세요:
make lint
LiteLLM은 타입 검사에 basedpyright를 사용합니다. CI는 포매팅에 ruff format --check 도 실행하며, 로컬에서 포매팅을 고치려면 make format 을 실행하세요.
5. PR 제출
- 변경을 GitHub 포크로 푸시
- 포크에서 Pull Request 열기
UI
1. 로컬 개발 환경 설정
1단계: 저장소 클론
git clone https://github.com/BerriAI/litellm.git
2단계: UI 대시보드 디렉터리로 이동
cd ui/litellm-dashboard
3단계: 의존성 설치
npm install
4단계: 개발 서버 시작
npm run dev
2. 테스트 추가
새 컴포넌트나 새 로직을 추가한다면 대응 테스트를 추가해야 합니다.
3. UI 유닛 테스트 실행
npm run test
4. UI 빌드
PR 제출 전 UI가 성공적으로 빌드되는지 확인하세요:
npm run build
5. PR 제출
- 변경을 GitHub 포크로 푸시
- 포크에서 Pull Request 열기
고급
LiteLLM Docker 이미지 빌드
LiteLLM Docker 이미지를 직접 빌드하고 실행하려면 다음 지침을 따르세요.
1단계: 저장소 클론
git clone https://github.com/BerriAI/litellm.git
2단계: Docker 이미지 빌드
Dockerfile.non_root 로 빌드:
docker build -f docker/Dockerfile.non_root -t litellm_test_image .
3단계: Docker 이미지 실행
config.yaml이 루트 디렉터리에 있는지 확인하세요. 이것이 LiteLLM proxy config 파일입니다.
docker run \
-v $(pwd)/proxy_config.yaml:/app/config.yaml \
-e DATABASE_URL="postgresql://xxxxxxxx" \
-e LITELLM_MASTER_KEY="sk-<paste-a-long-random-key>" \
-p 4000:4000 \
litellm_test_image \
--config /app/config.yaml --detailed_debug
LiteLLM Proxy를 로컬에서 실행
proxy/디렉터리로 이동:
cd litellm/litellm/proxy
- 프록시 실행:
python3 proxy_cli.py --config /path/to/config.yaml
# RUNNING on http://0.0.0.0:4000