파이프라인 실행 문제 해결

  • 아티클

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

파이프라인 실행이 완료되지 않으면 파이프라인 실행 요약 페이지에서 제공하는 진단 정보 및 로그를 사용하여 문제를 해결할 수 있습니다.

파이프라인 실행 요약 페이지의 스크린샷.

로그 보기

완료하지 못한 작업의 로그를 보려면 오류 메시지를 선택합니다.

파이프라인 실행 요약 페이지의 작업 오류 메시지 스크린샷

로그 페이지가 표시되고 오류가 선택됩니다. 이 예제에서는 명령이 cmd-line/>로 ech입력되는 echo 작업에 오류가 있습니다.

파이프라인 실행에 대한 진단 로그의 스크린샷

원시 로그 보기를 선택하여 작업에 대한 원시 로그를 볼 수 있으며 찾기를 사용하여 로그를 검색할 수 있습니다.

Azure DevOps의 로그 보기 옵션 스크린샷

실패한 작업의 로그에서 오류 정보와 태스크가 실패한 이유에 대한 단서를 검색합니다. 기본적으로 비언어적 로그는 파이프라인 실행에 의해 생성됩니다. 기본 로그가 문제의 원인을 나타내지 않는 경우 자세한 로그를 구성하여 자세한 정보를 얻을 수 있습니다.

오류 분석 페이지

문제 해결 지원은 오류 분석 페이지를 사용하여 사용할 수 있습니다 . 오류 정보 줄 위로 마우스를 이동하고 분석 보기 아이콘을 선택합니다.

파이프라인 실행 요약 페이지의 보기 분석 아이콘 스크린샷.

Azure DevOps Server에 대한 분석 보기 아이콘의 스크린샷

자체 호스팅 에이전트(또는 Microsoft 호스팅 에이전트의 호스트된 에이전트 이미지 정보)에 대한 에이전트 보기를 선택하여 파이프라인을 실행하는 데 사용되는 에이전트에 대한 자세한 정보를 확인하고 로그를 확인하여 파이프라인 실행 로그를 봅니다.

Azure DevOps 포털의 오류 분석 페이지 스크린샷

작업에 대한 정보를 보려면 런타임 세부 정보 아래의 작업 이름을 선택합니다.

오류 분석의 작업 세부 정보 스크린샷

이 예제에서는 에 오류가 ValueScript있음을 확인할 수 있습니다. 이 작업에 대한 설명서를 보려면 이 작업에 대해 선택합니다.

파이프라인 실행 요약 페이지 또는 로그 검색에서 문제가 명백하지 않은 경우 다음 일반적인 문제 섹션을 검사 추가 진단 정보를 포함하는 전체 로그 다운로드에 대한 자세한 내용은 파이프라인 문제를 진단하기 위해 로그 검토를 참조하세요.

일반적인 문제

실패한 파이프라인 실행에 대한 작업 인사이트

Azure DevOps는 실패한 파이프라인 실행 설정에 대한 Task Insights를 제공합니다. 이 설정을 사용하면 보고서를 볼 수 있는 링크와 함께 빌드 실패에 대한 팝업 알림을 제공합니다.

작업 인사이트 메트릭의 스크린샷.

이 설정을 구성하려면 미리 보기 기능으로 이동하고 실패한 파이프라인 실행에 대한 Task Insights를 찾아 원하는 설정을 선택합니다.

실패한 파이프라인 실행 설정에 대한 작업 인사이트 스크린샷

작업 시간 제한

파이프라인은 오랫동안 실행된 다음 작업 시간 제한으로 인해 실패할 수 있습니다. 작업 시간 제한은 사용 중인 에이전트에 따라 달라집니다. 무료 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 올바른지 확인합니다.

Team Foundation 버전 제어(TFVC) 문제

일부 파일을 다운로드하지 않는 원본 가져오기

이 특성은 명령의 로그 "모든 최신 파일"의 메시지로 특징지어 tf get 질 수 있습니다. 기본 제공 서비스 ID에 원본을 다운로드할 수 있는 권한이 있는지 확인합니다. ID 프로젝트 컬렉션 빌드 서비스 또는 프로젝트 빌드 서비스는 빌드 파이프라인의 일반 탭에서 선택한 권한 부여 범위에 따라 원본을 다운로드할 수 있는 권한이 필요합니다. 버전 제어 웹 UI에서 폴더 계층 구조의 모든 수준에서 프로젝트 파일을 찾아보고 보안 설정을 확인할 수 있습니다.

Team Foundation 프록시를 통해 원본 가져오기

Team Foundation 프록시를 통해 원본을 가져오기 위해 에이전트를 구성하는 가장 쉬운 방법은 에이전트가 사용자로 실행되도록 TFVC 프록시 서버를 가리키는 환경 변수 TFSPROXY 를 설정하는 것입니다.

Windows:

    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

macOS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

MSBUILD와 같은 명령줄 단계에서 파이프라인이 실패합니다.

빌드 또는 릴리스 실패가 Azure Pipelines/TFS 제품 문제(에이전트 또는 작업)의 결과인지 여부를 좁히는 것이 유용합니다. 빌드 및 릴리스 실패는 외부 명령으로 인해 발생할 수도 있습니다.

실패한 태스크에 의해 실행된 정확한 명령줄에 대한 로그를 확인합니다. 명령줄에서 로컬로 명령을 실행하려고 시도하면 문제가 재현될 수 있습니다. 사용자 고유의 컴퓨터에서 로컬로 명령을 실행하거나 컴퓨터에 로그인하고 명령을 서비스 계정으로 실행하는 것이 유용할 수 있습니다.

예를 들어 빌드 파이프라인의 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 실행합니다. 경우에 따라 여러 프로세스 파일 액세스 문제와 같은 문제가 발생할 수 있습니다.

빌드 작업에 인수를 /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

서비스 연결과 관련된 문제를 해결하려면 서비스 연결 문제 해결을 참조 하세요.

파이프라인이 에이전트의 청력을 중지했습니다.

파이프라인이 다음과 같은 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 사용률을 포함하여 로그에서 리소스 사용률을 확인할 수 있습니다. 파이프라인이 완료되면 로그에서 각 단계에 대한 Agent environment resources 항목을 검색합니다.

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 파일 복사 작업을 사용하여 웹 사이트에 콘텐츠를 업로드할 수 있습니다. 콘텐츠 업로드에 설명된 도구를 사용하여 웹 컨테이너에 콘텐츠를 업로드할 수 있습니다.

다음 단계