파이프라인 실행 문제 해결

  • 아티클
  • 읽는 데 44분 걸림

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

이 항목에서는 일반적인 문제 해결 지침을 제공합니다. .NET Core에 대한 특정 문제 해결은 .NET Core 문제 해결을 참조하세요.

참고

Microsoft TFS(Team Foundation Server) 2018 이하 버전에서 빌드 및 릴리스 ‘파이프라인’은 ‘정의’라고 하며 ‘실행’은 ‘빌드’, ‘서비스 연결’은 ‘서비스 엔드포인트’, ‘스테이지’는 ‘환경’, ‘작업’은 ‘단계’라고 합니다.

다음 문제 해결 섹션을 사용하여 파이프라인 문제를 진단할 수 있습니다. 대부분의 파이프라인 오류는 이러한 범주 중 하나에 속합니다.

파이프라인이 트리거되지 않음

파이프라인이 전혀 시작되지 않는 경우 다음과 같은 일반적인 트리거 관련 문제를 확인합니다.

참고

실행이 시작되지 않을 수 있는 또 다른 이유는 마지막 사용자가 Azure DevOps에서 로그아웃한 후 5분 후에 조직이 휴면 상태가 되므로 그런 다음 각 빌드 파이프라인이 한 번 더 실행됩니다. 예를 들어 조직에서 휴면 상태인 경우:

  • 조직의 야간 코드 빌드는 누군가가 다시 로그인할 때까지 하룻밤만 실행됩니다.
  • 다른 Git 리포지토리의 CI 빌드는 누군가가 다시 로그인할 때까지 실행을 중지합니다.

UI 설정이 YAML 트리거 설정을 재정의합니다.

YAML 파이프라인은 파이프라인 설정 UI에서 해당 trigger 및 pr 트리거 설정을 재정의할 수 있습니다. 사용자 trigger 또는 pr 트리거가 실행되지 않는 것 같으면 해당 설정을 확인합니다. 파이프라인을 편집하는 동안 ... 를 선택한 다음 트리거합니다.

파이프라인 설정 UI

리포지토리에 사용할 수 있는 트리거 유형(연속 통합 또는 끌어오기 요청 유효성 검사)은 여기 설정에서 YAML 트리거 재정의를 확인합니다.

여기에서 YAML 트리거를 재정의합니다.

끌어오기 요청 트리거는 Azure Repos 지원되지 않습니다.

pr 트리거가 실행되지 않고 Azure Repos 사용하는 경우 트리거가 Azure Repos 지원되지 않기 때문 pr 입니다. Azure Repos Git에서 분기 정책은 끌어오기 요청 빌드 유효성 검사를 구현하는 데 사용됩니다. 자세한 내용은 끌어오기 요청 유효성 검사에 대한 분기 정책을 참조하세요.

CI 및 PR 트리거에서 잘못 구성된 분기 필터

YAML PR 또는 CI 트리거를 정의할 때 분기 및 경로에 대한 절과 exclude 절을 모두 include 지정할 수 있습니다. 절이 include 커밋의 세부 정보와 일치하고 절에서 해당 절을 exclude 제외하지 않는지 확인합니다.

중요

YAML PR 또는 CI 트리거를 정의할 때 포함되도록 명시적으로 구성된 분기만 실행을 트리거합니다. 포함이 먼저 처리된 다음 제외가 목록에서 제거됩니다. 제외를 지정하지만 포함을 지정하지 않으면 아무 것도 트리거되지 않습니다. 자세한 내용은 pr 및 트리거를 참조하세요.

YAML PR 또는 CI 트리거를 정의할 때 분기, 태그 및 exclude 경로에 대한 절과 절을 모두 include 지정할 수 있습니다. 절이 include 커밋의 세부 정보와 일치하고 절에서 해당 절을 exclude 제외하지 않는지 확인합니다. 자세한 내용은 pr 및 트리거를 참조하세요.

참고

절 없이 절을 excludeinclude 지정하는 경우 절에서 include 지정하는 * 것과 같습니다.

예약된 트리거 표준 시간대 변환

YAML 예약 트리거는 UTC 표준 시간대를 사용하여 설정됩니다. 예약된 트리거가 적시에 실행되지 않는 것 같으면 날짜 설정도 고려하여 UTC와 현지 표준 시간대 간의 변환을 확인합니다. 자세한 내용은 예약된 트리거를 참조하세요.

UI 설정이 YAML 예약 트리거를 재정의합니다.

YAML 파이프라인에 YAML 예약 트리거와 UI가 정의된 예약된 트리거가 모두 있는 경우 UI 정의 예약 트리거만 실행됩니다. YAML 파이프라인에서 YAML에서 정의된 예약된 트리거를 실행하려면 파이프라인 설정 UI에 정의된 예약된 트리거를 제거해야 합니다.

YAML 파이프라인에서 파이프라인 설정 UI에 액세스하려면 파이프라인을 편집하고 ... 및 트리거를 선택합니다.

파이프라인 설정 UI

예약된 트리거를 모두 제거합니다.

파이프라인 설정 UI에서 예약된 트리거를 삭제합니다.

모든 UI 예약 트리거가 제거되면 YAML 예약 트리거 실행을 시작하려면 푸시를 수행해야 합니다. 자세한 내용은 예약된 트리거를 참조하세요.

파이프라인 큐는 있지만 에이전트를 가져오지 않습니다.

파이프라인이 큐에 대기하지만 에이전트를 가져오지 않는 경우 다음 항목을 확인합니다.

참고

다음 시나리오에서는 병렬 작업을 소비하지 않습니다.

  • 릴리스 파이프라인 또는 다단계 YAML 파이프라인을 사용하는 경우 실행은 스테이지에 적극적으로 배포될 때만 병렬 작업을 사용합니다. 릴리스는 승인 또는 수동 개입을 기다리는 동안 병렬 작업을 사용하지 않습니다.
  • 릴리스 파이프라인을 사용하여 서버 작업을 실행하거나 배포 그룹에 배포하는 경우 병렬 작업을 사용하지 않습니다.

Mer informasjon: 파이프라인에서 병렬 작업을 사용하는 방법, 배포 전 승인 추가, 서버 작업, 배포 그룹

병렬 작업 제한 - 사용 가능한 에이전트가 없거나 무료 한도에 도달했습니다.

현재 다른 파이프라인을 실행 중인 경우 남은 병렬 작업이 없거나 무료 한도에 도달했을 수 있습니다.

제한을 확인하려면 프로젝트 설정, 병렬 작업으로 이동합니다.

파이프라인 동시 작업

제한을 검토한 후 동시성을 확인하여 현재 실행 중인 작업 수와 사용 가능한 작업 수를 확인합니다.

현재 다른 파이프라인을 실행 중인 경우 남은 병렬 작업이 없거나 무료 한도에 도달했을 수 있습니다.

Azure DevOps에서 방화벽 뒤의 Azure 密钥保管库 액세스할 수 없습니다.

파이프라인에서 Azure 密钥保管库 액세스할 수 없는 경우 방화벽이 Azure DevOps Services 에이전트 IP 주소를 차단할 수 있습니다. 주간 JSON 파일에 게시된 IP 주소는 허용 목록에 있어야 합니다. 자세한 내용은 Microsoft 호스팅 에이전트: 네트워킹을 참조하세요.

동시성이 충분하지 않습니다.

얼마나 많은 동시성이 있는지 확인하려면 다음을 수행합니다.

  1. 제한을 확인하려면 프로젝트 설정, 병렬 작업으로 이동합니다.

    동시 파이프라인 제한

    로그로 이동 https://dev.azure.com/{org}/_settings/buildqueue?_a=concurrentJobs하거나 로그에서 병렬 작업 관리를 선택하여 이 페이지에 도달할 수도 있습니다.

    병렬 작업 관리

  2. 동시성을 확인할 풀(Microsoft 호스팅 또는 자체 호스팅 풀)을 결정하고 진행 중인 작업 보기를 선택합니다.

  3. 현재 실행 중인 X/X 작업이라는 텍스트가 표시됩니다. 두 숫자가 모두 같으면 현재 실행 중인 작업이 완료될 때까지 작업이 대기합니다.

    진행 중인 작업 보기

    프로젝트 설정에서 에이전트 풀을 선택하여 대기 중인 작업을 비롯한 모든 작업을 볼 수 있습니다.

    큐에 대기된 작업 보기

    이 예제에서 동시 작업 제한은 하나의 작업이 실행되고 다른 하나는 대기 중인 작업입니다. 이 예제와 같이 모든 에이전트가 작업을 실행 중인 경우 추가 작업이 큐에 대기 The agent request is not running because all potential agents are running other requests. Current position in queue: 1될 때 다음 메시지가 표시됩니다. 이 예제에서 작업은 큐의 다음 위치이므로 해당 위치는 1입니다.

작업이 승인을 기다리고 있을 수 있습니다.

파이프라인이 승인을 기다리고 있기 때문에 다음 단계로 이동하지 않을 수 있습니다. 자세한 내용은 승인 및 검사 정의를 참조하세요.

사용 가능한 모든 에이전트가 사용 중

모든 에이전트가 현재 사용 중인 경우 작업이 대기할 수 있습니다. 에이전트를 확인하려면 다음을 수행합니다.

  1. https://dev.azure.com/{org}/_settings/agentpools로 이동

  2. 이 예제 FabrikamPool에서 확인할 에이전트 풀을 선택하고 에이전트를 선택합니다.

    에이전트 상태

    이 페이지에는 현재 온라인/오프라인으로 사용 중인 모든 에이전트가 표시됩니다. 이 페이지에서 풀에 에이전트를 추가할 수도 있습니다.

에이전트의 기능과 일치하지 않는 요구 사항

파이프라인에 에이전트의 기능을 충족하지 않는 요구 사항이 있는 경우 파이프라인이 시작되지 않습니다. 일부 에이전트에만 원하는 기능이 있으며 현재 다른 파이프라인을 실행 중인 경우, 해당 에이전트 중 하나를 사용할 수 있게 될 때까지 파이프라인이 중단됩니다.

에이전트 및 파이프라인에 대해 지정된 기능 및 요구 사항을 확인하려면 기능을 참조하세요.

참고

기능 및 요구 사항은 일반적으로 자체 호스팅 에이전트에서만 사용됩니다. 파이프라인에 에이전트의 시스템 기능과 일치하지 않는 요구 사항이 있는 경우 일치하는 기능을 사용하여 에이전트에 명시적으로 레이블을 지정하지 않으면 파이프라인에 에이전트가 표시되지 않습니다.

TFS 에이전트 연결 문제

에이전트 연결을 테스트하는 동안 구성 실패(온-프레미스 TFS에만 해당)

Testing agent connection.
VS30063: You are not authorized to access http://<SERVER>:8080/tfs

에이전트를 구성하는 동안 위의 오류가 수신되면 TFS 컴퓨터에 로그온합니다. IIS(인터넷 정보 서비스) 관리자를 시작합니다. 익명 인증이 사용하도록 설정되어 있는지 확인합니다.

는 TFS 익명 인증을 사용하도록 설정됨

에이전트가 통신을 잃었습니다.

이 문제는 다음과 같은 오류 메시지로 특징지어집니다.

The job has been abandoned because agent did not renew the lock. Ensure agent is running, not sleeping, and has not lost communication with the service.

이 오류는 에이전트가 몇 분 동안 서버와의 통신을 끊은 것을 나타낼 수 있습니다. 에이전트 컴퓨터에서 네트워크 또는 기타 중단을 제외하려면 다음을 확인합니다.

  • 자동 업데이트가 꺼져 있는지 확인합니다. 업데이트에서 컴퓨터를 다시 부팅하면 위의 오류로 인해 빌드 또는 릴리스가 실패합니다. 이러한 유형의 중단을 방지하기 위해 제어된 방식으로 업데이트를 적용합니다. 에이전트 컴퓨터를 다시 부팅하기 전에 먼저 에이전트가 풀 관리 페이지에서 비활성화된 것으로 표시되고 실행 중인 빌드가 완료되도록 해야 합니다.
  • 절전 모드 설정이 꺼져 있는지 확인합니다.
  • 에이전트가 가상 머신에서 실행 중인 경우 몇 분 동안 컴퓨터의 상태에 심각한 영향을 미칠 수 있는 실시간 마이그레이션 또는 기타 VM 유지 관리 작업을 방지합니다.
  • 에이전트가 가상 머신에서 실행되는 경우 동일한 운영 체제 업데이트 권장 사항 및 절전 모드 설정 권장 사항이 호스트 컴퓨터에 적용됩니다. 또한 호스트 컴퓨터에 여러 가지 영향을 주는 기타 유지 관리 작업도 있습니다.
  • 성능 모니터 로깅 또는 기타 상태 메트릭 로깅은 이러한 유형의 오류를 에이전트 컴퓨터(디스크, 메모리, 페이지 파일, 프로세서, 네트워크)의 제한된 리소스 가용성과 상호 연결하는 데 도움이 될 수 있습니다.
  • 오류와 네트워크 문제의 상관 관계를 지정하는 또 다른 방법은 서버를 무기한 ping하고 타임스탬프와 함께 출력을 파일에 덤프하는 것입니다. 정상 간격(예: 20초 또는 30초)을 사용합니다. Azure Pipelines를 사용하는 경우 인터넷 도메인(예: bing.com)을 ping하려고 합니다. 온-프레미스 TFS 서버를 사용하는 경우 동일한 네트워크에서 서버를 ping하려고 합니다.
  • 컴퓨터의 네트워크 처리량이 적절한지 확인합니다. 온라인 속도 테스트를 수행하여 처리량을 확인할 수 있습니다.
  • 프록시를 사용하는 경우 에이전트가 프록시를 사용하도록 구성되어 있는지 확인합니다. 에이전트 배포 항목을 참조하세요.

TFS 작업 에이전트가 시작되지 않음

이는 웹 콘솔의 "에이전트가 요청되기를 기다리는 중"이라는 메시지로 특징지어질 수 있습니다. TFSJobAgent(표시 이름: Visual Studio Team Foundation 백그라운드 작업 에이전트) Windows 서비스가 시작되었는지 확인합니다.

잘못 구성된 알림 URL(1.x 에이전트 버전)

이는 웹 콘솔의 "에이전트에서 콘솔 출력 대기 중"이라는 메시지로 특징지어질 수 있으며 결국 프로세스 시간이 초과될 수 있습니다.

알림 URL이 일치하지 않을 경우 작업자가 서버에 연결하지 못할 수 있습니다. Team Foundation 관리 콘솔, 애플리케이션 계층을 참조하세요. 1.x 에이전트는 구성된 URL을 사용하여 메시지 큐를 수신 대기합니다. 그러나 작업 메시지를 큐에서 끌어오면 작업자 프로세스는 알림 URL을 사용하여 서버와 다시 통신합니다.

서비스 성능 저하에 대한 Azure DevOps 상태 확인

Azure DevOps Service 상태 포털에서 에이전트의 큐 시간 증가와 같이 서비스 저하를 일으킬 수 있는 문제를 확인합니다. 자세한 내용은 Azure DevOps Service 상태를 참조하세요.

파이프라인을 완료하지 못함

파이프라인이 에이전트를 가져오지만 완료하지 못하는 경우 다음과 같은 일반적인 문제를 확인합니다. 문제가 이러한 문제 중 하나와 일치하지 않는 경우 로그 가져오기를 참조하여 문제를 진단합니다.

작업 시간 제한

파이프라인은 오랫동안 실행된 다음 작업 시간 제한으로 인해 실패할 수 있습니다. 작업 시간 제한은 사용 중인 에이전트에 따라 밀접하게 달라집니다. 무료 Microsoft 호스팅 에이전트에는 개인 리포지토리의 경우 작업당 최대 60분, 공용 리포지토리의 경우 360분의 최대 시간 제한이 있습니다. 작업에 대한 최대 시간 제한을 늘리려면 다음 중 어느 것을 선택할 수 있습니다.

  • 사용된 리포지토리에 관계없이 모든 작업에 대해 360분을 제공하는 Microsoft 호스팅 에이전트 구입
  • 자체 호스팅 에이전트를 사용하여 에이전트로 인한 시간 제한 문제를 배제합니다.

작업 시간 제한에 대한 Mer informasjon.

참고

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 프로젝트 컬렉션 빌드 서비스 또는 Project Build Service 는 빌드 파이프라인의 일반 탭에서 선택한 권한 부여 범위에 따라 원본을 다운로드할 수 있는 권한이 필요합니다. 버전 제어 웹 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 상호 작용 및 기타 제한 사항이 있습니다.

사용 중인 파일 또는 폴더 오류

사용 중인 파일 또는 폴더 오류는 다음과 같은 오류 메시지로 표시되는 경우가 많습니다.

  • 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 Build 작업은 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 Build 작업을 사용하는 경우 기본적으로 추가되는 "/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 파일이 실행되지 않습니다.

종속성을 설치하려면 Serviço de Aplicativo 배포 태스크에서 배포 후 스크립트를 사용합니다. 다음 예제에서는 배포 후 스크립트에서 사용해야 하는 명령을 보여줍니다. 시나리오에 대한 스크립트를 업데이트할 수 있습니다.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

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

Storage Explorer 사용하여 Azure Pipelines를 통해 Azure DevOps에서 정적 웹 사이트에 .css 및 .js 같은 정적 콘텐츠를 배포합니다.

이 시나리오에서는 Azure 파일 복사 작업을 사용하여 웹 사이트에 콘텐츠를 업로드할 수 있습니다. 콘텐츠 업로드에 설명된 도구를 사용하여 웹 컨테이너에 콘텐츠를 업로드할 수 있습니다.

문제를 진단하는 로그 가져오기

이전 제안 중 어떤 제안도 문제와 일치하지 않는 경우 로그의 정보를 사용하여 실패한 파이프라인을 진단할 수 있습니다.

먼저 완료된 빌드 또는 릴리스의 로그를 확인합니다. 파이프라인 실행 요약으로 이동하고 작업을 선택하여 로그를 볼 수 있습니다. 특정 작업이 실패하는 경우 해당 작업에 대한 로그를 확인합니다.

파이프라인 빌드 요약에서 로그를 보는 것 외에도 추가 진단 정보를 포함하는 전체 로그를 다운로드할 수 있으며 문제 해결에 도움이 되도록 자세한 로그를 구성할 수 있습니다.

로그를 구성하고 사용하는 방법에 대한 자세한 내용은 로그를 검토하여 파이프라인 문제 진단을 참조하세요.

나는 더 많은 도움이 필요합니다. 버그를 발견했습니다. 나는 제안을 가지고있다. 어디로 가야 하나요?

구독, 청구 및 기술 지원 받기

문제를 보고하거나 Developer Community 피드백을 제출합니다.

귀하의 제안을 환영합니다.