프로젝트를 빌드하고 테스트할 수 없는 에이전트는 자체 작업을 검증할 수 없습니다. 품질 게이트, 리뷰, 그리고 풀 요청에 대한 신뢰도 등 모든 후속 과정은 이러한 명령어가 올바르게 적용되는지에 달려 있습니다.
프로젝트를 생성할 때 Coroid가 이를 감지합니다. 감지된 내용을 확인해 보세요.
Coroid에 필요한 사항
| 명령어 | 용도 |
|---|---|
| 설치 | 깨끗한 작업 공간에서 종속 요소 복원 |
| 빌드 | 프로젝트가 컴파일되는지 확인 |
| 테스트 | 테스트 스위트를 실행하고 결과 확인 |
각 작업마다 작업 공간은 깨끗하고 일회용이므로, 모든 명령어는 캐시되거나 미리 설치된 항목 없이 새로 클론된 상태에서 정상적으로 작동해야 합니다.
감지 과정에서 흔히 발생하는 오류 유형
모노레포.명령어가 하위 디렉터리에 위치하거나 작업 공간 필터가 필요한 경우가 있습니다. 루트 수준에 명령어가 존재하더라도 잘못된 동작을 할 수 있습니다.
설정 단계.코드 생성, 마이그레이션 또는 고정 데이터 구축이 선행되어야 하는 테스트 스위트의 경우, 감지 과정에서는 테스트 명령어만 인식하고 필수 전제 조건은 간과할 수 있습니다.
서비스 종속성.데이터베이스, 캐시 또는 큐가 실행되어야 하는 테스트의 경우,
해당 서비스가 가동 중이라고 가정하면localhost:5432깔끔한 작업 공간에서는 테스트가 실패하게 됩니다.
환경 변수.저장소에 포함되지 않은.env에서 설정값을 읽는 테스트 스위트의 경우
잘못된 구성으로 인한 증상
변경 사항과 무관한 이유로 검증 단계에서 작업이 실패하는 경우가 해당됩니다. 요청된 내용과 관계없이 모든 작업에서 동일한 단계에서 동일한 오류가 발생합니다.
코드가 작성되기 전에 첫 번째로 오류가 발생한다면 대부분 빌드 명령어 문제입니다. 변경 사항 적용 후에 오류가 발생한다면 보통 테스트 명령어나 테스트가 의존하는 요소의 문제입니다.
컨테이너
프로젝트를 컨테이너화할 수 있는 경우, Coroid는 이를 실행 환경으로 활용할 수 있습니다. 이 방식은 서비스 종속 요소와 환경 불일치 문제를 한 번에 해결해 주며, 컨테이너 내에 관련 설정이 이미 포함되어 있기 때문입니다.
테스트를 실행할 수 있는 유효한 Dockerfile이나 Compose 파일이 있다면, 이는 일반적으로 가장 신뢰할 수 있는 구성입니다.
언어 지원
에이전트는 모든 언어에서 작동하지만, Coroid가 자체적으로 검증할 수 있는 범위는 언어별로 다릅니다. 특히 의미론적 탐색 기능의 경우가 그렇습니다.언어 지원 및 에이전트 환경에서 작업 공간에 설치된 항목과 언어 서버가 지원되는 언어를 확인하세요.
이 명령어들을 올바르게 설정하는 것이 사용하는 언어보다 더 중요합니다. 지원 언어가 제한적인 경우라도 올바른 빌드 및 테스트 쌍이 지원이 잘 되는 언어에서의 잘못된 설정보다 더 효과적입니다.