개요
이 가이드에는 CI Visibility에서 프로그램 방식으로 파이프라인 실행을 설정하는 방법을 설명하고 CI Visibility가 지원하는 파이프라인 실행 유형을 정의했습니다.
이 가이드는 공개 CI Visibility Pipelines API를 사용해 생성한 파이프라인에 적용됩니다. 다른 CI 공급자와의 통합은 다를 수 있습니다.
데이터 모델
파이프라인 실행은 트레이스로 모델링되며(APM 분산 트레이스와 유사), 여기에서는 스팬이 파이프라인에서 서로 다른 부분의 실행을 나타냅니다. 파이프라인 실행을 나타내는 CI Visibility 데이터 모델은 다음과 같은 4개 레벨로 구성됩니다.
| 레벨 이름 | 설명 |
| | |
| 파이프라인(필수) | 다른 모든 레벨을 하위 항목으로 포함하는 toplevel 루트 스팬입니다. 이는 처음부터 끝까지 파이프라인 하나의 전체 실행을 나타냅니다. 이 레벨은 일부 CI 공급자에서는 때때로 build 또는 workflow로 불립니다. |
| 스테이지 | 사용자 정의 이름 아래에서 작업의 그룹화 역할을 합니다. 일부 CI 공급자에는 이 레벨이 없습니다. |
| 작업 | 명령이 실행되는 가장 작은 단위의 작업입니다. 이 레벨의 모든 태스크는 노드 하나에서 수행해야 합니다. |
| 단계 | 일부 CI 공급자의 경우, 이 레벨은 셸 스크립트 또는 작업 안에서 실행되는 액션을 나타냅니다. |
파이프라인, 스테이지, 작업 또는 단계가 완료되면 실행 데이터가 Datadog으로 전송됩니다. Pipeline Visibility를 설정하려면 지원되는 CI 공급자 목록을 참조하세요. CI 공급자 또는 워크플로가 지원되지 않는 경우, 공개 API 엔드포인트를 사용해 파이프라인 실행을 CI Visibility로 보낼 수 있습니다.
스테이지, 작업, 단계는 상위 파이프라인과 파이프라인 이름이 정확히 같아야 합니다. 불일치하는 경우, 일부 파이프라인에 스테이지, 작업, 단계 정보가 누락될 수 있습니다. 예를 들어 작업 요약 표에 작업이 누락될 수 있습니다.
파이프라인 고유 ID
한 레벨 안의 모든 파이프라인 실행에는 각각 고유한 식별자가 있어야 합니다. 예를 들어 파이프라인과 작업의 고유한 ID는 같을 수 있어도, 파이프라인 두 개의 고유한 ID는 같을 수 없습니다.
타임스탬프가 서로 다른 ID를 반복해서 보내면 사용자 인터페이스가 바람직하지 않은 동작을 할 수 있습니다. 예를 들어 플레임(flame) 그래프에 다른 파이프라인 실행의 스팬 태그가 표시될 수 있습니다. 타임스탬프가 같은 중복 ID가 전송되면 마지막으로 수신된 파이프라인 실행의 값만 저장됩니다.
파이프라인 실행 유형
정상 실행
파이프라인 실행의 정상 실행은 아래와 같은 흐름을 따릅니다.
공급자에 따라 일부 레벨이 누락될 수 있습니다. 예를 들어 스테이지가 존재하지 않거나, 작업이 병렬로 또는 순차적으로 실행되거나 이 두 방식을 조합하여 실행될 수 있습니다.
각 구성 요소가 완료되고 나면 Datadog에 해당 실행을 나타내는 데 필요한 모든 데이터와 함께 페이로드를 보내야 합니다. Datadog이 이 데이터를 처리해 파이프라인 이벤트로 저장한 다음 CI Visibility에 표시합니다. 파이프라인 실행을 Datagod에 보내기 전에 종료해야 합니다.
전체 재시도
파이프라인의 전체 재시도에는 서로 다른 파이프라인 고유 ID가 있어야 합니다.
공개 API 엔드포인트에서 previous_attempt 필드를 채워 이전 재시도에 연결할 수 있습니다. 재시도는 Datadog에서 각각 별개의 파이프라인 실행으로 취급되며, 시작 시간과 종료 시간은 해당 재시도만 포함해야 합니다.
부분 재시도
한 파이프라인 내에서 작업의 하위 집합을 재시도하는 경우, 새 파이프라인 고유 ID를 포함한 새 파이프라인 이벤트를 보내야 합니다. 모든 새 작업의 페이로드는 새 파이프라인 고유 ID에 연결되어야 합니다. 이를 이전 재시도에 연결하려면 previous_attempt 필드를 추가하세요.
부분 재시도 또한 별도의 파이프라인으로 취급됩니다. 시작 시간 및 종료 시간에 원래 재시도 시간을 포함하면 안 됩니다. 부분 재시도의 경우, 이전 시도에서 실행한 작업의 페이로드를 보내지 마세요. 또한 부분 재시도에서는 partial_retry 필드를 true로 설정하여 실행 시간을 계산할 때 집계에서 제외해야 합니다.
예를 들어, 이름이 P인 파이프라인에 서로 다른 작업 세 개, 즉 J1, J2, J3가 있고 이들이 순차적으로 실행되었습니다. P의 첫 번째 실행에서는 J1 및 J2만 실행되고 J2는 실패합니다.
따라서 다음과 같은 총 3개의 페이로드를 보내야 합니다.
J1의 작업 페이로드, 여기에 ID J1_1 및 파이프라인 ID P_1 포함.J2의 작업 페이로드, 여기에 ID J2_1 및 파이프라인 ID P_1 포함.P의 파이프라인 페이로드, 여기에 ID P_1 포함.
이 파이프라인의 부분 재시도가 있었고 J2에서 시작했으며, 나머지 작업이 모두 성공한다고 합시다.
그러면 페이로드 3개를 추가로 보내야 합니다.
J2의 작업 페이로드, 여기에 ID J2_2 및 파이프라인 ID P_2 포함.J3의 작업 페이로드, 여기에 ID J3_1 및 파이프라인 ID P_2 포함.P의 파이프라인 페이로드, 여기에 ID P_2 포함.
ID의 실제 값은 중요하지 않습니다. 위에서 지정한 파이프라인 실행에 따라 값을 정확하게 수정하는 것이 중요합니다.
차단된 파이프라인
파이프라인이 수동 개입이 필요해서 무기한 차단된 경우, 해당 파이프라인이 차단된 상태에 도달하자마자 파이프라인 이벤트 페이로드를 보내야 합니다. 파이프라인 상태는 blocked로 설정해야 합니다.
나머지 파이프라인 데이터는 다른 파이프라인 고유 ID를 사용해 별도의 페이로드로 보내야 합니다. 두 번째 파이프라인에서는 is_resumed를 true로 설정해 해당 실행이 차단된 파이프라인에서 재개되었음을 알릴 수 있습니다.
다운스트림 파이프라인
한 파이프라인이 다른 파이프라인의 하위 항목으로 트리거되는 경우, parent_pipeline 필드를 해당 상위 파이프라인의 세부 정보로 채워야 합니다.
수동 파이프라인
파이프라인이 수동으로 트리거되는 경우, is_manual 필드를 true로 설정해야 합니다.
Git 정보
파이프라인 실행을 트리거한 커밋의 Git 정보를 제공하는 것이 강력히 권장됩니다. Git 정보가 없는 파이프라인 실행은 최근 코드 변경 사항 페이지에 표시되지 않습니다. 최소한 리포지토리 URL, 커밋 SHA와 다른 이메일 하나가 필요합니다. 자세한 내용은 공개 API 엔드포인트 사양을 참조하세요.
참고 자료
