최근에 TFS의 "숨겨진 기능"을 발견했습니다.이 기능을 사용하면 의견에 ***NO_CI***이 포함되어 있으면 CI 빌드가 시작되지 않도록 할 수 있습니다.*** NO_CI ***가 여전히 지속적인 intregration 빌드를 유발하는 이유는 무엇입니까?
나는 TFS를 집에서 운영하고 있는데, 이것은 작은 트릭이 매력처럼 작동합니다.
직장에서 우리는 TFS 2010도 사용하고 있습니다.이 설정으로 CI 빌드가 시작되지 않도록하지는 못합니다.
내 질문에, 실제로 어떤 프로세스가 ***NO_CI***이 CI 빌드를 차단할지 여부를 결정하는 데 있는지 확인합니다. 나의 초기 생각은 빌드 템플릿을 살펴 보는 것이었다. 나는 너무 명백한 것을 보지 못했다. 아무도 이것에 부딪쳤습니까? 올바른 방향으로 나를 가리킬 수 있습니까?
이 문제는 제 실수의 실수였습니다. 빌드가 성공적으로 완료되면 몇 가지 자동 체크 인이 제출됩니다. 첫 번째 것은 ***NO_CI***이고 두 번째는 포함되지 않았습니다. 두 번째 체크인이 작업 공간에 매핑 된 경로로 두 번째 체크인이 수행되고 있다는 것을 깨닫지 못했습니다. 따라서 첫 번째 체크인은 CI 빌드가 시작되지 않는 두 번째 체크인이었습니다.
기본적으로 체크인이 발생하면 AT는 빌드 구성 요소에 체크인에 대해 알리기 위해 이벤트를 가로 채고 실행합니다. 그런 다음 빌드 구성 요소는 영향을받는 빌드 정의의 트리거 유형 (연속 통합, 롤링 빌드, 예약 된 빌드, gated-checkin 등)에 따라 적절한 조치를 취합니다.
체크 인 주석에 ***NO_CI*** 문자열이 포함되어 있지만 변경 세트가 여전히 CI 빌드를 트리거하는 경우 AT의 이벤트 로그를보고 "TF215041 : 변경 세트를 처리하지 못했습니다. n ".
팀에서 gated checkin 빌드 정의를 사용하는 경우 빌드 템플릿에서 ***NO_CI*** 주석을 사용하지 않도록 선택했는지 확인하여 게이트 체크 인 변경 집합에서 CI를 트리거 할 수있게하십시오.
재생 Duat에게 감사드립니다. 제 무지를 용서해주십시오, AT는 뭐니? – dkpatt
응용 프로그램 계층을 나타냅니다. –