코드 검사에 자동 설정을 사용하는 경우 AI 기반 에이전트는 리포지토리를 분석하고 테스트 프레임워크를 식별하며 검토 준비가 된 검사 워크플로를 사용하여 끌어오기 요청을 엽니다.
이 기능을 사용하는 데 추가 비용은 없습니다.
에이전트 작동 방식
에이전트는 다음 세 단계로 작동합니다.
- 검색: 에이전트는 CI 구성, 설명서 및 빌드 파일을 읽고 프로젝트 구조를 이해하고 테스트 프레임워크를 식별합니다.
- 실행: 에이전트는 종속성을 설치하고, 프로젝트를 빌드하고, 검사를 사용하도록 설정된 테스트를 실행합니다. 검사 도구가 아직 구성되지 않은 경우 에이전트는 프로젝트 구성(예
vitest.config.ts: 또는jest.config.js)에 추가합니다. - 워크플로 통합: 에이전트가 유효한 검사 보고서를 생성하는 경우 리포지토리에 끌어오기 요청에 대한 테스트를 실행하는 워크플로가 이미 GitHub Actions 있는지 확인합니다. 이 경우 에이전트는 검사 업로드 단계를 사용하여 해당 워크플로를 보강합니다. 그렇지 않은 경우 새 워크플로 파일을 만들고 끌어오기 요청을 엽니다.
에이전트가 중지되는 경우
에이전트는 다음과 같은 상황에서 끌어오기 요청을 열기 전에 중지할 수 있습니다.
- 테스트를 찾을 수 없습니다. 에이전트가 계측할 테스트를 찾을 수 없으므로 검사를 생성할 필요가 없습니다.
- 빌드를 재현할 수 없습니다. 프라이빗 레지스트리, 독점 SDK 또는 시스템 종속성이 없으므로 에이전트가 테스트 제품군을 확인하지 못하게 됩니다.
에이전트가 중지되거나 예기치 않은 결과를 생성하는 경우 에이전트의 세션 로그에서 자세한 내용을 검토할 수 있습니다. 리포지토리의 작업 탭으로 이동하여 워크플로 생성 시도와 연결된 세션을 찾습니다.
- 지원되지 않는 검사 보고서 변환입니다. 에이전트는 집계된 카운터만 노출하는 보고서에서 Cobertura XML을 다시 구성하지 않습니다. 예를 들어 JaCoCo XML에는 신뢰할 수 있는 Cobertura 업로드에 충분한 선 및 분기 구조가 없으므로 JaCoCo XML만 생성하는 JVM 프로젝트에는 수동 설정이 필요할 수 있습니다.
끌어오기 요청 결과
참고
에이전트는 코드 변경 내용이 없는 초기 계획 커밋을 사용하여 끌어오기 요청을 즉시 엽니다. 실제 구현 커밋은 일반적으로 몇 분 후에 도착합니다. 끌어오기 요청에 처음에 변경된 파일이 0개 표시되면 몇 분 정도 기다렸다가 페이지를 새로 고칩니다.
에이전트가 끌어오기 요청을 성공적으로 열면 끌어오기 요청이 다음 상태 중 하나일 수 있습니다.
- 병합 가능한 as-is: 워크플로가 CI에서 성공적으로 완료되고 적용 범위가 올바르게 업로드됩니다.
- 반복할 준비가 완료되었습니다 . 워크플로는 실행되지만 조정이 필요합니다(예: 비밀 누락, 자체 호스팅 실행기 구성 또는 로컬 확인과 CI 간의 경로 차이).
- 참조로 유용: 유지 관리자는 에이전트의 끌어오기 요청을 검색한 빌드 및 테스트 명령의 시작점으로 사용하여 검사 자체를 구성하는 것을 선호할 수 있습니다.