Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
파이프라인 실행이 완료되지 않으면 파이프라인 실행 요약 페이지의 진단 정보 및 로그를 사용하여 문제를 해결합니다. 이 가이드에서는 로그, 오류 분석 도구 및 일반적인 문제 해결 기술을 사용하여 파이프라인 오류를 진단하기 위한 지침을 제공합니다. 근본 원인을 식별하고 파이프라인이 원활하게 실행되도록 솔루션을 구현하는 방법을 알아봅니다.
로그 보기
완료되지 않은 작업에 대한 로그를 보려면 오류 메시지를 선택합니다.
로그 페이지에 선택한 오류가 표시됩니다. 이 예에서는 cmd-line 작업에서 echo 명령이 ech로 입력되는 오류가 있습니다.
원시 로그 보기를 선택하여 작업에 대한 원시 로그를 볼 수 있으며 찾기를 사용하여 로그를 검색할 수 있습니다.
실패한 작업의 로그에서 오류 정보와 태스크가 실패한 이유에 대한 단서를 검색합니다. 기본적으로 비언어적 로그는 파이프라인 실행에 의해 생성됩니다. 기본 로그가 문제의 원인을 나타내지 않는 경우 자세한 로그를 구성하여 자세한 정보를 얻을 수 있습니다.
오류 분석 페이지
문제 해결 지원은 오류 분석 페이지를 사용하여 사용할 수 있습니다. 오류 정보 줄 위로 마우스를 이동하고 분석 보기 아이콘을 선택합니다.
자체 호스팅 에이전트(또는 Microsoft 호스팅 에이전트의 호스트된 에이전트 이미지 정보)에 대한 에이전트 보기를 선택하여 파이프라인을 실행하는 데 사용되는 에이전트에 대한 자세한 정보를 확인하고 로그를 확인하여 파이프라인 실행 로그를 봅니다.
작업에 대한 정보를 보려면 런타임 세부 정보 아래 작업의 이름을 선택합니다.
이 예제에서는 Value의 Script에 오류가 있음을 확인할 수 있습니다.
이 작업에 대한 설명서를 보려면 이 작업에 대해 선택합니다.
파이프라인 실행 요약 페이지나 로그를 검색해도 문제가 명확하지 않으면 일반적인 문제 섹션을 확인하고, 로그 검토를 통해 파이프라인 문제를 진단하여 보다 자세한 진단 정보를 포함한 전체 로그 다운로드에 대한 정보를 참조하십시오.
일반적인 문제
- 이 파이프라인은 이 실행을 계속하기 전에 리소스에 액세스할 수 있는 권한이 필요합니다.
- 작업 시간 제한
- 코드 다운로드 문제
- MSBUILD와 같은 명령줄 단계에서 파이프라인이 실패합니다.
- 사용 중인 파일 또는 폴더 오류
- 간헐적이거나 일관되지 않은 MSBuild 오류
- 프로세스 응답 중지
- 여러 플랫폼에 대한 줄 끝
- '(작은따옴표)가 추가된 변수
- 서비스 연결 관련 문제
- 파이프라인이 에이전트로부터 소식을 듣지 못했습니다.
실패한 파이프라인 실행에 대한 작업 인사이트
Azure DevOps는 실패한 파이프라인 실행 설정에 대한 Task Insights 를 제공합니다. 이 설정을 사용하면 보고서를 볼 수 있는 링크와 함께 빌드 실패에 대한 팝업 알림을 제공합니다.
이 설정을 구성하려면 미리 보기 기능으로 이동하고 실패한 파이프라인 실행에 대한 Task Insights를 찾아 원하는 설정을 선택합니다.
실패한 실행에 대한 알림
Azure DevOps에는 실패한 파이프라인 실행에 대한 빌드 인 알림이 포함되어 있습니다. 알림을 사용하려면 다음을 수행합니다.
- 프로젝트에 대한 프로젝트 설정>알림 으로 이동합니다.
- 받을 알림 유형을 선택합니다. 파이프라인 실행이 실패할 때마다 알림을 받도록 하려면 빌드 실패를 선택합니다.
이 파이프라인은 이 실행을 계속하기 전에 리소스에 액세스할 수 있는 권한이 필요합니다.
파이프라인이 시작되지 않거나 다음과 같은 This pipeline needs permission to access a resource before this run can continue오류 메시지가 표시되는 경우 파이프라인이 서비스 연결 또는 에이전트 풀과 같은 리소스에서 권한 부여가 실행될 때까지 기다리고 있는지 확인합니다.
- 파이프라인으로 이동하여 수동으로 실행을 시작합니다.
- 이 실행이 계속되기 전에 이 파이프라인에 리소스에 액세스할 수 있는 권한이 필요하다는 메시지가 표시됩니다. 메시지 옆에 있는 보기를 선택합니다.
- 검토 대기 화면에서 [허용]을 선택하고 확인 화면에서 [허용]을 다시 선택합니다.
이 작업은 파이프라인을 리소스의 권한 있는 사용자로 명시적으로 추가합니다.
에이전트 풀에 액세스하도록 파이프라인에 권한을 부여하는 방법에는 두 가지가 있습니다.
- 특정 파이프라인 권한 부여 - 풀에서 실행할 Azure DevOps 프로젝트의 특정 파이프라인에 개별적으로 권한을 부여합니다.
- 열린 액세스 구성 - 해당 프로젝트의 모든 파이프라인에 사용할 수 있도록 프로젝트 수준에서 에이전트 풀을 구성합니다.
특정 파이프라인 권한 부여
다음과 같은 This pipeline needs permission to access a resource before this run can continue메시지를 받을 때 이전 섹션의 절차에 따라 에이전트 풀에서 실행할 특정 파이프라인에 개별적으로 권한을 부여할 수 있습니다.
다음 절차를 수행하여 권한 있는 목록에서 파이프라인을 수동으로 추가하고 제거할 수도 있습니다. 이 절차는 Azure DevOps 조직의 프로젝트 수준에서 수행됩니다.
- Azure DevOps에서 프로젝트 설정, 에이전트 풀로 이동하여 자체 호스팅 풀을 선택하고 보안을 선택합니다.
- 권한 있는 목록에 파이프라인을 추가하도록 선택합니다 + .
- X(액세스 취소)를 선택하여 권한 있는 목록에서 파이프라인을 제거합니다.
열린 액세스 구성
일부 리소스를 사용하면 각 새 파이프라인 정의에 명시적 권한 부여가 필요하지 않도록 Open 액세스를 구성할 수 있습니다.
Open 액세스를 구성하려면 프로젝트 관리자 권한이 필요합니다.
에이전트 풀에 대한 열기 액세스를 구성하려면 다음을 수행합니다.
- Azure DevOps에서 프로젝트 설정, 에이전트 풀로 이동하여 자체 호스팅 풀을 선택하고 보안을 선택합니다.
- 추가 작업을 선택하고 공개 액세스를 눌러 공개 액세스를 활성화한 다음, 공개 액세스를 다시 선택하여 확인합니다.
- 열려 있는 액세스를 취소하려면 권한 제한(Restrict permission)을 선택합니다.
다른 리소스 종류에 대해 Open Access를 사용할 수 있는지 여부를 검토하려면 Azure Pipelines의 보안 관리 및 Open 액세스 검색을 참조하세요.
에이전트 풀에 대한 열기 액세스에 대한 자세한 내용은 개별 에이전트 풀에 대한 파이프라인 권한 설정 및 파이프라인 권한을 참조하세요.
작업 시간 초과
파이프라인은 오랫동안 실행된 다음 작업 시간 제한으로 인해 실패할 수 있습니다. 작업 시간 제한은 사용 중인 에이전트에 따라 달라집니다. 무료 Microsoft 호스팅 에이전트의 최대 제한 시간은 개인 리포지토리의 경우 작업당 60분, 공용 리포지토리의 경우 360분입니다.
작업에 대한 최대 시간 제한을 늘리려면 다음 중 원하는 것을 선택할 수 있습니다.
- 사용된 리포지토리에 관계없이 모든 작업에 대해 360분을 제공하는 Microsoft 호스팅 에이전트 구입
- 자체 호스팅 에이전트를 사용하여 에이전트로 인한 시간 초과 문제를 배제합니다.
작업 시간 제한에 대해 자세히 알아봅니다.
비고
Microsoft 호스팅 에이전트 작업의 시간이 초과된 경우 파이프라인 시간 제한이 작업의 최대 시간 제한보다 큰 값으로 설정되어 있는지 확인합니다. 확인하려면 시간 제한을 참조하세요.
코드 다운로드 문제
체크 아웃 단계에서 파이프라인이 실패합니다.
파이프라인이 속한 프로젝트와 다른 프로젝트의 조직에 있는 Azure Repos Git 리포지토리에서 checkout 단계를 사용하는 경우, 작업 권한 부여 범위를 현재 프로젝트로 제한 설정을 해제해야 합니다. 그렇지 않으면, 범위가 지정된 빌드 ID의 단계에 따라 파이프라인이 리포지토리에 액세스할 수 있는지 확인하십시오.
제한된 작업 권한 부여 범위로 인해 파이프라인이 리포지토리에 액세스할 수 없는 경우 오류가 Git fetch failed with exit code 128 표시되고 로그에 다음과 유사한 항목이 포함됩니다. Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.
Could not find a project that corresponds with the repository사용하여 파이프라인이 즉시 실패하는 경우 checkout 단계 또는 리포지토리 리소스 선언에서 프로젝트 및 리포지토리 이름이 올바른지 확인합니다.
TFVC(Team Foundation 버전 제어) 문제
일부 파일을 다운로드하지 않는 원본 가져오기
명령의 "모든 파일을 최신 상태로 유지"라는 메시지가 로그에 tf get 표시될 수 있습니다. 기본 제공 서비스 ID에 원본을 다운로드할 수 있는 권한이 있는지 확인합니다. ID 프로젝트 컬렉션 빌드 서비스 또는 프로젝트 빌드 서비스는 빌드 파이프라인의 탭 일반에서 선택된 권한 부여 범위에 따라 원본을 다운로드할 수 있는 권한이 필요합니다. 버전 제어 웹 UI에서 폴더 계층 구조의 모든 수준에서 프로젝트 파일을 찾아보고 보안 설정을 확인할 수 있습니다.
Team Foundation 프록시를 통해 원본 가져오기
Team Foundation 프록시를 통해 원본을 가져오기 위해 에이전트를 구성하는 가장 쉬운 방법은 에이전트가 사용자로 실행되도록 TFVC 프록시 서버를 가리키는 환경 변수 TFSPROXY 설정하는 것입니다.
윈도우:
set TFSPROXY=http://tfvcproxy:8081
setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable
맥OS/리눅스:
export TFSPROXY=http://tfvcproxy:8081
MSBUILD와 같은 명령줄 단계에서 파이프라인이 실패합니다.
빌드 또는 릴리스 실패가 Azure Pipelines 제품 문제(에이전트 또는 작업)의 결과인지 여부를 좁히는 것이 유용합니다. 빌드 및 릴리스 실패는 외부 명령으로 인해 발생할 수도 있습니다.
실패한 태스크에 의해 실행된 정확한 명령줄에 대한 로그를 확인합니다. 명령줄에서 로컬로 명령을 실행하려고 시도하면 문제가 재현될 수 있습니다. 사용자 고유의 컴퓨터에서 로컬로 명령을 실행하거나 컴퓨터에 로그인하고 명령을 서비스 계정으로 실행하는 것이 유용할 수 있습니다.
예를 들어 빌드 파이프라인의 MSBuild 부분에서 문제가 발생합니까(예: MSBuild 또는 Visual Studio Build 작업을 사용하고 있나요)? 그렇다면 동일한 인수를 사용하여 로컬 컴퓨터에서 동일한 MSBuild 명령을 실행해 봅니다. 로컬 컴퓨터에서 문제를 재현할 수 있는 경우 다음 단계는 MSBuild 문제를 조사하는 것입니다.
파일 레이아웃
빌드에 필요한 도구, 라이브러리, 헤더 및 기타 항목의 위치는 호스트된 에이전트에서 로컬 컴퓨터와 다를 수 있습니다. 이러한 파일 중 하나를 찾을 수 없어 빌드가 실패하는 경우 아래 스크립트를 사용하여 에이전트의 레이아웃을 검사할 수 있습니다. 이렇게 하면 누락된 파일을 추적하는 데 도움이 될 수 있습니다.
임시 위치에 새 YAML 파이프라인을 만듭니다(예: 문제 해결을 위해 만든 새 리포지토리).
작성된 대로 스크립트는 경로의 디렉터리를 검색합니다.
필요에 따라 SEARCH_PATH= 줄을 편집하여 다른 위치를 검색할 수 있습니다.
# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
SEARCH_PATH=$PATH # or any colon-delimited list of paths
IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
echo "##[debug] Found directories"
for element in "${PathDirs[@]}"; do
echo "$element"
done;
echo;
echo;
echo "##[debug] Found files"
for element in "${PathDirs[@]}"; do
find "$element" -type f
done
# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
$SEARCH_PATH=$Env:Path
Write-Host "##[debug] Found directories"
ForEach ($Dir in $SEARCH_PATH -split ";") {
Write-Host "$Dir"
}
Write-Host ""
Write-Host ""
Write-Host "##[debug] Found files"
ForEach ($Dir in $SEARCH_PATH -split ";") {
Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
Write-Host $_.FullName
}
}
로컬 명령 프롬프트와 에이전트 간의 차이점
로컬 컴퓨터에서 명령을 실행하고 에이전트에서 빌드 또는 릴리스를 실행할 때 몇 가지 차이점이 적용됩니다. 에이전트가 Linux, macOS 또는 Windows에서 서비스로 실행되도록 구성된 경우 대화형 로그온 세션 내에서 실행되지 않습니다. 대화형 로그온 세션이 없으면 UI 상호 작용 및 기타 제한 사항이 존재합니다.
사용 중인 파일 또는 폴더 오류
File or folder in use 오류는 다음과 같은 오류 메시지로 표시됩니다.
Access to the path [...] is denied.The process cannot access the file [...] because it is being used by another process.Access is denied.Can't move [...] to [...]
문제 해결 단계:
사용 중인 파일 및 폴더 검색
Windows에서 프로세스 모니터 와 같은 도구는 특정 디렉터리에서 파일 이벤트의 추적을 캡처하는 것입니다. 또는 스냅샷의 경우 프로세스 탐색기 또는 핸들 과 같은 도구를 사용할 수 있습니다.
바이러스 백신 제외
파일을 검사하는 바이러스 백신 소프트웨어는 빌드 또는 릴리스 중에 파일 또는 폴더 사용 오류를 일으킬 수 있습니다. 에이전트 디렉터리에 대한 바이러스 백신 제외 및 구성된 "작업 폴더"를 추가하면 바이러스 백신 소프트웨어를 방해 프로세스로 식별하는 데 도움이 될 수 있습니다.
MSBuild 및 /nodeReuse:false
빌드하는 동안 MSBuild를 호출하는 경우 인수 /nodeReuse:false(약식 /nr:false)를 전달해야 합니다. 그렇지 않으면 빌드가 완료된 후에도 MSBuild 프로세스가 계속 실행됩니다. 프로세스는 잠재적인 후속 빌드를 예상하여 일정 시간 동안 남아 있습니다.
MSBuild의 이 기능은 MSBuild 프로세스의 작업 디렉터리와의 충돌로 인해 디렉터리를 삭제하거나 이동하려는 시도를 방해할 수 있습니다.
MSBuild 및 Visual Studio 빌드 작업은 이미 MSBuild에 전달된 인수에 /nr:false 추가합니다. 그러나 사용자 고유의 스크립트에서 MSBuild를 호출하는 경우 인수를 지정해야 합니다.
MSBuild 및 /maxcpucount:[n]
기본적으로 MSBuild 및 Visual Studio Build와 같은 빌드 작업은 스위치를 사용하여 MSBuild를 실행합니다. 경우에 따라 여러 프로세스 파일 액세스 문제와 같은 문제가 발생할 수 있습니다.
빌드 작업에 /m:1 인수를 추가하여 MSBuild가 한 번에 하나의 프로세스만 실행하도록 합니다.
MSBuild의 동시 프로세스 기능을 활용할 때 사용 중인 파일 문제가 발생할 수 있습니다. 인수 /maxcpucount:[n] 지정하지 않으면(약식 /m:[n]) MSBuild에서 단일 프로세스만 사용하도록 지시합니다. MSBuild 또는 Visual Studio 빌드 작업을 사용하는 경우 기본적으로 추가되는 "/m" 인수를 재정의하려면 "/m:1"을 지정해야 할 수 있습니다.
간헐적이거나 일관되지 않은 MSBuild 오류
간헐적이거나 일관되지 않은 MSBuild 오류가 발생하는 경우 MSBuild에 단일 프로세스만 사용하도록 지시합니다. 간헐적이거나 일관되지 않은 오류는 대상 구성이 MSBuild의 동시 프로세스 기능과 호환되지 않음을 나타낼 수 있습니다. MSBuild 및 /maxcpucount:[n] 참조하세요.
프로세스 응답 중지
프로세스는 원인 응답 및 문제 해결 단계를 중지합니다.
입력 대기 중
응답을 중지하는 프로세스는 프로세스가 입력을 기다리고 있음을 나타낼 수 있습니다.
대화형 로그온 세션의 명령줄에서 에이전트를 실행하면 프로세스에서 입력을 위한 대화 상자가 있는지 여부를 식별하는 데 도움이 될 수 있습니다.
에이전트를 서비스로 실행하면 입력하라는 메시지가 표시되지 않도록 프로그램을 제거하는 데 도움이 될 수 있습니다. 예를 들어, .NET에서 프로그램은 System.Environment.UserInteractive 부울 값을 의존하여 프롬프트를 표시할지 여부를 결정할 수 있습니다. 에이전트가 Windows 서비스로 실행되는 경우 값은 false입니다.
프로세스 파일 저장
프로세스의 덤프를 분석하면 교착 상태 프로세스가 무엇을 기다리고 있는지 식별하는 데 도움이 될 수 있습니다.
WiX 프로젝트
사용자 지정 MSBuild 로거를 사용할 때 WiX 프로젝트를 빌드하면 WiX가 출력 스트림을 기다리다가 교착 상태에 빠질 수 있습니다. 추가 MSBuild 인수 /p:RunWixToolsOutOfProc=true 를 추가하면 문제가 해결되었습니다.
여러 플랫폼에서의 줄 바꿈 형식
여러 플랫폼에서 파이프라인을 실행하는 경우 줄 바꿈 방식의 차이로 인해 문제가 발생할 수 있습니다. 지금까지 Linux 및 macOS는 LF(줄 바꿈) 문자를 사용했으며 Windows는 캐리지 리턴과 CRLF(줄 바꿈)를 사용했습니다. Git은 리포지토리에서는 LF로, Windows 작업 디렉토리에서는 CRLF로 자동으로 줄 끝을 지정하여 차이를 조정하려고 합니다.
대부분의 Windows 도구는 LF 전용 끝으로 잘 작동하며 이 자동 동작으로 인해 해결되는 것보다 더 많은 문제가 발생할 수 있습니다.
줄 끝부분에 따라 문제가 발생하는 경우 어디서나 LF를 선호하도록 Git을 구성하는 것이 좋습니다.
이렇게 하려면 리포지토리의 루트에 .gitattributes 파일을 추가합니다.
해당 파일에서 다음 줄을 추가합니다.
* text eol=lf
'(작은따옴표)가 추가된 변수
파이프라인에 명령을 사용하여 변수를 설정하는 Bash 스크립트가 ##vso 포함된 경우 설정한 변수 값에 다른 ' 변수가 추가될 수 있습니다.
이는 set -x와의 상호 작용으로 인해 발생합니다.
솔루션은 변수를 설정하기 전에 일시적으로 set -x를 사용하지 않도록 설정하는 것입니다.
이를 위한 Bash 구문은 set +x입니다.
set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x
이유는 무엇입니까?
많은 Bash 스크립트에는 디버깅을 지원하는 set -x 명령이 포함됩니다.
Bash는 실행된 명령을 정확히 추적하고 stdout에 에코합니다.
이렇게 하면 에이전트가 ##vso 명령을 두 번 인식하게 되어, 두 번째에는 Bash가 ' 문자를 끝에 추가합니다.
예를 들어 다음 파이프라인을 고려합니다.
steps:
- bash: |
set -x
echo ##vso[task.setvariable variable=MY_VAR]my_value
stdout에서 에이전트는 다음 두 줄을 확인합니다.
##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'
에이전트에 첫 번째 줄이 표시되면 MY_VAR 올바른 값인 "my_value"로 설정됩니다.
그러나 두 번째 줄이 표시되면 에이전트는 줄의 끝까지 모든 것을 처리합니다.
MY_VAR 가 "my_value"로 설정되어 있습니다.
스크립트가 실행될 때 Python 애플리케이션용 라이브러리가 설치되지 않음
Python 애플리케이션이 배포되면 경우에 따라 CI/CD 파이프라인이 실행되고 코드가 성공적으로 배포되지만 모든 종속성 라이브러리 설치를 담당하는 requirements.txt 파일이 실행되지 않습니다.
종속성을 설치하려면 App Service 배포 작업에서 배포 후 스크립트를 사용합니다. 다음 예제에서는 배포 후 스크립트에서 사용해야 하는 명령을 보여줍니다. 시나리오에 대한 스크립트를 업데이트할 수 있습니다.
D:\home\python364x64\python.exe -m pip install -r requirements.txt
서비스 연결 관련 문제
서비스 연결과 관련된 문제를 해결하려면 서비스 연결 문제 해결을 참조하세요. 인증에 워크로드 ID를 사용하여 서비스 연결 문제를 구체적으로 해결하려면 워크로드 ID 서비스 연결 문제 해결을 참조하세요.
파이프라인이 에이전트와의 통신을 중단했습니다.
We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection.같은 메시지와 함께 파이프라인이 실패하는 경우 에이전트의 리소스 사용률을 확인하여 에이전트 머신에 리소스가 부족했는지 확인합니다.
Sprint 228부터 Azure Pipelines 로그에는 각 단계에 대한 리소스 사용률 메트릭이 포함됩니다.
Azure DevOps Services를 사용하는 경우, 자세한 로그를 사용하도록 설정하면 디스크 사용량, 메모리 사용량 및 CPU 사용률을 포함하여 로그에서 리소스 사용률을 확인할 수 있습니다. 파이프라인이 완료되면 검색합니다.
2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%
추가 리소스 사용률 로그를 캡처하는 방법에 대한 자세한 내용은 캡처 리소스 사용률 세부 정보를 참조하세요.
Storage Explorer가 Azure Pipelines를 통해 Azure DevOps에서 정적 웹 사이트에 .css 및 .js 같은 정적 콘텐츠를 배포하도록 설정
이 시나리오에서는 Azure 파일 복사 작업을 사용하여 웹 사이트에 콘텐츠를 업로드할 수 있습니다. 콘텐츠 업로드에 설명된 도구를 사용하여 웹 컨테이너에 콘텐츠를 업로드할 수 있습니다.
다음 단계
- 로그를 검토 하여 추가 진단 도구를 발견합니다.