Skip to Content
KoDevelopersDevelopment자동화 및 트리아지 프로세스

자동화 및 트리아지 프로세스

이 문서는 이슈와 풀 리퀘스트를 관리하고 트리아지하기 위해 사용하는 자동화 프로세스에 대한 자세한 개요를 제공합니다. 목표는 신속한 피드백을 제공하고 기여물이 효율적으로 검토 및 통합되도록 하는 것입니다. 이 자동화를 이해하면 기여자로서 무엇을 기대할 수 있는지, 저장소 봇과 어떻게 상호작용하면 되는지 알 수 있습니다.

핵심 원칙: 이슈와 풀 리퀘스트

가장 먼저, 거의 모든 풀 리퀘스트(PR)는 해당 이슈에 연결되어야 합니다. 이슈는 “무엇을”과 “왜”(버그 또는 기능)를 설명하고, PR은 “어떻게”(구현)를 설명합니다. 이 분리는 작업을 추적하고, 기능의 우선순위를 정하고, 명확한 이력 컨텍스트를 유지하는 데 도움이 됩니다. 자동화는 이 원칙을 중심으로 구축됩니다.

상세 자동화 워크플로

저장소에서 실행되는 특정 자동화 워크플로의 분류입니다.

1. 이슈를 열 때: Qwen Triage

이슈를 생성할 때 상호작용하는 첫 번째 봇입니다. 초기 분석을 수행하고 올바른 라벨을 적용하는 것이 역할입니다.

  • 워크플로 파일: .github/workflows/qwen-triage.yml
  • 실행 시점: 이슈가 생성, 편집, 재개된 직후, 또는 관리자가 수동으로 트리아지를 요청할 때.
  • 수행 작업:
    • Qwen 모델을 사용하여 이슈의 제목과 본문을 상세한 가이드라인 집합에 대해 분석합니다.
    • area/* 라벨 하나 적용: 이슈를 프로젝트의 기능 영역으로 분류합니다 (예: area/ux, area/models, area/platform).
    • kind/* 라벨 하나 적용: 이슈 유형을 식별합니다 (예: kind/bug, kind/enhancement, kind/question).
    • priority/* 라벨 하나 적용: 설명된 영향도를 기반으로 P0(긴급)에서 P3(낮음)까지 우선순위를 할당합니다.
    • status/need-information 적용 가능: 이슈에 중요한 세부 정보(로그나 재현 단계 등)가 부족하면 추가 정보를 요청하는 플래그가 지정됩니다.
    • status/need-retesting 적용 가능: 이슈가 6개 이상 이전 CLI 버전을 참조하면 현재 버전에서 재테스트하도록 플래그가 지정됩니다.
  • 사용자가 해야 할 일:
    • 이슈 템플릿을 최대한 완전하게 작성합니다. 자세한 정보를 제공할수록 트리아지 정확도가 높아집니다.
    • status/need-information 라벨이 추가되면 요청된 세부 정보를 댓글로 제공하세요.
    • 관리자는 @qwen-code /triage를 댓글로 달아 트리아지를 다시 실행할 수 있습니다.

2. 풀 리퀘스트를 열 때: Continuous Integration (CI)

이 워크플로는 모든 변경 사항이 병합되기 전에 품질 기준을 충족하는지 확인합니다.

  • 워크플로 파일: .github/workflows/ci.yml
  • 실행 시점: 풀 리퀘스트의 모든 푸시 시.
  • 수행 작업:
    • Lint: 코드가 프로젝트의 포맷팅 및 스타일 규칙을 준수하는지 확인합니다.
    • Test: macOS, Windows, Linux 및 여러 Node.js 버전에 걸쳐 전체 자동화 테스트 세트를 실행합니다. CI 프로세스에서 가장 시간이 많이 걸리는 부분입니다.
    • Post Coverage Comment: 모든 테스트가 성공적으로 통과되면 봇이 PR에 댓글을 게시합니다. 이 댓글은 변경 사항이 테스트로 얼마나 잘 커버되는지에 대한 요약을 제공합니다.
  • 사용자가 해야 할 일:
    • 모든 CI 체크가 통과되도록 합니다. 모든 것이 성공하면 커밋 옆에 초록색 체크마크 ✅가 나타납니다.
    • 체크가 실패하면(빨간색 “X” ❌), 실패한 체크 옆의 “Details” 링크를 클릭하여 로그를 확인하고, 문제를 식별하고, 수정 사항을 푸시합니다.

3. 릴리스 자동화

이 워크플로는 Qwen Code의 새 버전을 패키징하고 게시하는 프로세스를 처리합니다.

  • 워크플로 파일: .github/workflows/release.yml
  • 실행 시점: “야간” 릴리스를 위한 일일 스케줄, 그리고 공식 패치/마이너 릴리스를 위한 수동 실행.
  • 수행 작업:
    • 자동으로 프로젝트를 빌드하고, 버전 번호를 올리고, 패키지를 npm에 게시합니다.
    • 생성된 릴리스 노트와 함께 GitHub에 해당 릴리스를 생성합니다.
  • 사용자가 해야 할 일:
    • 기여자로서 이 프로세스에 대해 아무것도 할 필요가 없습니다. PR이 main 브랜치에 병합되면 다음 야간 릴리스에 변경 사항이 포함됩니다.

이 자세한 개요가 도움이 되기를 바랍니다. 자동화나 프로세스에 대해 질문이 있으면 언제든지 문의하세요!

Last updated on
통합 테스트패키지 개요