실패한 빌드 또는 릴리스 파이프라인 작업 및 스테이지 다시 시작
해당 단계 또는 파이프라인에서 실패하거나 취소된 빌드, 릴리스 변경 내용 또는 파이프라인을 다시 실행하거나 재배포합니다 Azure DevOps . 다시 시도는 파이프라인 UI에 DevOps 새 실행을 만드는 대신 연속 실행으로 표시됩니다.
파이프라인 또는 스테이지 재실행 Azure DevOps
에서 실패 또는 취소된 빌드 또는 릴리스 파이프라인을 다시 실행하거나 작업을 변경할 수 있습니다 Azure DevOps. 다시 실행은 의 첫 번째 실행 ServiceNow DevOps과 동일한 파이프라인 실행의 일부로 처리됩니다. 전체 파이프라인 또는 실패하거나 취소된 특정 작업 및 스테이지를 다시 실행할 수 있습니다. 이제 단계 또는 파이프라인을 다시 시작할 때마다 새 변경 요청을 생성하는 대신 변경 요청을 재사용하도록 선택할 수 있습니다.
attemptNumber 재실행을 추적하는 데 도움이 되는 매개변수가 페이로드에 추가됩니다. 연결된 테스트 요약, 소프트웨어 품질 검사 결과, 커밋, 모든 재실행 시도에 해당하는 작업 항목도 에서 업데이트됩니다 ServiceNow DevOps.
를 Azure 호출 REST API를 사용하여 변경 제어 구성 사용하는 경우 빌드 및 릴리스 파이프라인에 대해 지정된 구문 형식으로 페이로드 본문에 시도 횟수 매개변수를 추가해야 합니다. 시도 횟수 매개변수를 지정하지 않으면 기본 시도 횟수는 1로 설정됩니다.
"attemptNumber": "$(system.jobAttempt)""attemptNumber": "$(Release.AttemptNumber)"변경 요청 재사용
변경 사용 작업이 다시 실행되고 이전 실행/시도에 대한 변경 요청이 있는 경우 기본 시스템 "DevOps 변경 요청 재사용 가능성 결정 하위 플로우"를 사용하여 이전 변경 요청을 재사용하거나 새 변경 요청을 생성하도록 선택할 수 있습니다. 이 하위 플로우의 기본 구현을 사용하면 변경 요청이 구현 상태 또는 구현 후 상태인 경우 이전 시도의 변경 요청을 재사용할 수 있습니다. 변경 요청이 다른 상태인 경우 기본적으로 작업을 다시 실행하면 새 변경 요청이 생성됩니다. 기존 동작에 따라 테스트 요약 및 검사와 같은 모든 관련 상세 정보가 새로 생성되고 커밋 및 작업 항목은 새 변경 요청에 대해 변경되지 않은 상태로 유지됩니다.
예를 들어 변경 요청이 승인된 후 특정 단계에서 파이프라인이 실패하고 해당 단계를 다시 실행하는 경우입니다. 변경 요청이 재사용되고, 연결된 테스트 요약 및 소프트웨어 품질 검사가 수행되고, 아티팩트와 연결된 커밋 및 작업 항목이 사용자가 승인한 동일한 변경 요청과 연결됩니다.
재사용성에 대한 사용자 지정 논리를 적용하려면 기존 하위 플로우를 복사하고, 변경 사항을 적용하고, 게시한 다음 아래의 새 하위 플로우 이름을 업데이트할 수 있습니다. .
일반 기본 시스템 플로우에서 변경이 생성되면 변경 요청에 대한 결정을 내린 후 단계 실행 기록의 필드를 업데이트할 State 때 'DevOps 플로우 사용자 지정'를 사용합니다. 그러나 변경을 재사용할 경우 생성 중인 변경 요청의 첫 번째 트리거 조건이 충족되지 않습니다. 작업이 재실행될 때 변경 요청이 재사용될 때마다 기본 시스템 하위 플로우 'DevOps 변경 요청 재사용 가능성 모델 하위 플로우'가 대신 트리거됩니다. 이 하위 플로우의 기본 구현은 모델 변경 요청 플로우와 DevOps 유사합니다. 다음에서 사용자 지정 하위 플로우를 생성하고 하위 플로우 이름을 업데이트할 수 있습니다 . .
파이프라인 UI 변경 사항
- 카드를 클릭하여 해당 스테이지의 최신 시도를 봅니다.
- 두 번 이상 실행되는 단계 또는 스테이지와 관련된 모든 단계 실행 및 관련 정보를 보려면 모든 시도 뷰 링크를 클릭합니다.
- 변경 보기 링크에는 최근 시도와 연결된 변경 요청이 표시됩니다.