파이프라인 실행 문제 해결

Azure Pipelines | Azure DevOps Server 2020년 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015

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

참고

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

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

파이프라인이 트리거되지 않습니다.

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

참고

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

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

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

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

파이프라인 설정 UI

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

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

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

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

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

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

중요

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

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

참고

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

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

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

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

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

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

파이프라인 설정 UI

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

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

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

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

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

참고

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

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

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

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

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

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

동시 작업 Pipelines

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

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

Azure DevOps 방화벽 뒤의 Azure Key Vault 액세스할 수 없습니다.

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

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

동시성 양을 확인하려면 다음을 수행합니다.

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

    동시 파이프라인 제한

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

    병렬 작업 관리

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

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

    진행 중인 작업 보기

    Project 설정에서에이전트 풀을 선택하여 대기 중인 작업을 포함한 모든 작업을 볼 수 있습니다.

    큐에 대기된 작업 보기

    이 예제에서 동시 작업 제한은 1개이며, 하나의 작업이 실행 중이고 다른 하나는 큐에 대기됩니다. 이 예제와 같이 모든 에이전트가 작업을 실행 중이면 추가 작업이 큐에 대기될 때 메시지가 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 서비스 상태 포털에서 에이전트의 큐 시간 증가와 같이 서비스 저하를 일으킬 수 있는 문제를 확인합니다. 자세한 내용은 Azure DevOps 서비스 상태를 참조하세요.

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

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

작업 시간

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

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

작업 시간 제한 에 대해 자세히 알아봅니다.

참고

Microsoft 호스팅 에이전트 작업의 시간이 초과되는 경우 작업의 최대 시간 제한보다 작은 파이프라인 시간 초과를 지정하지 않았는지 확인합니다. 확인하려면 시간 초과를 참조하세요.

코드 다운로드 문제

체크 아웃 단계에서 내 파이프라인이 실패합니다.

파이프라인과 다른 프로젝트에 있는 checkout 조직의 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 Project 컬렉션 빌드 서비스 또는 Project 빌드 서비스 에 소스를 다운로드할 수 있는 권한이 필요 합니다. 버전 제어 웹 UI에서 폴더 계층 구조의 모든 수준에 있는 프로젝트 파일을 탐색 하 고 보안 설정을 확인할 수 있습니다.

Team Foundation Proxy를 통해 소스 가져오기

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

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 빌드 작업을 사용 하 고 있습니까?) 이 경우 동일한 인수를 사용 하 여 로컬 컴퓨터에서 동일한 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 빌드 작업은 이미 /nr:false MSBuild에 전달 된 인수에 추가 됩니다. 그러나 사용자 고유의 스크립트에서 MSBuild를 호출 하는 경우에는 인수를 지정 해야 합니다.

MSBuild 및/maxcpucount: [n]

기본적으로 MSBuildVisual Studio 빌드와 같은 빌드 작업은 스위치를 사용 하 여 MSBuild를 실행 합니다 . 일부 경우에는 여러 프로세스 파일 액세스 문제와 같은 문제가 발생할 수 있습니다.

/m:1빌드 작업에 인수를 추가 하 여 MSBuild 한 번에 하나의 프로세스만 실행 되도록 합니다.

MSBuild의 동시 처리 기능을 활용 하면 파일 사용 문제가 발생할 수 있습니다. 인수를 지정 하지 않으면 /maxcpucount:[n] (약식 /m:[n] ) MSBuild 단일 프로세스만 사용 하도록 지시 합니다. MSBuild 또는 Visual Studio 빌드 작업을 사용 하는 경우 "/m: 1"을 지정 하 여 기본적으로 추가 되는 "/m" 인수를 재정의 해야 할 수 있습니다.

간헐적 이거나 일치 하지 않는 MSBuild 오류

MSBuild 오류가 간헐적으로 발생 하거나 일치 하지 않는 경우 단일 프로세스만 사용 하도록 MSBuild 지시 하세요. 일시적 또는 일관 되지 않은 오류는 대상 구성이 MSBuild의 동시 처리 기능과 호환 되지 않음을 나타낼 수 있습니다. MSBuild 및/maxcpucount: [n]을참조 하세요.

프로세스의 응답이 중지 됨

프로세스에서 응답을 중지 하 고 문제를 해결 하는 단계:

입력 대기 중

응답을 중지 하는 프로세스는 프로세스가 입력을 기다리는 중임을 나타낼 수 있습니다.

대화형으로 로그온 한 세션의 명령줄에서 에이전트를 실행 하면 프로세스에서 입력에 대 한 대화 상자를 표시 하는지 여부를 확인 하는 데 도움이 될 수 있습니다.

에이전트를 서비스로 실행 하면 입력 메시지를 표시 하지 않고 프로그램을 제거 하는 데 도움이 될 수 있습니다. 예를 들어 .NET에서 프로그램은 UserInteractive 부울을 사용 하 여 메시지를 표시할지 여부를 결정할 수 있습니다. Windows 서비스로 실행 되는 경우 값은 false입니다.

덤프 처리

프로세스 덤프를 분석 하면 교착 상태 프로세스가 대기 중인 작업을 식별 하는 데 도움이 될 수 있습니다.

WiX 프로젝트

사용자 지정 MSBuild로 거를 사용 하는 경우 wix 프로젝트를 빌드하면 출력 스트림에서 대기 하는 교착 상태가 발생할 수 있습니다. 추가 MSBuild 인수를 추가 하면 /p:RunWixToolsOutOfProc=true 문제를 해결할 수 있습니다.

여러 플랫폼에 대 한 줄 끝

여러 플랫폼에서 파이프라인을 실행 하는 경우 다른 줄 끝에서 문제가 발생할 수도 있습니다. 지금까지, Linux 및 macos에서 캐리지 리턴과 줄 바꿈 (CRLF)을 사용 하 여 Windows 하는 동안 줄 바꿈 (LF) 문자를 사용 했습니다. 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

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

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

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

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

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

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

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

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

추가 도움이 필요 합니다. 버그가 발견 되었습니다. 제안이 있습니다. 어디에서 이동 하나요?

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

개발자 Community에서 문제를 보고 하거나 의견을 제출 합니다.

제안 사항을 환영 합니다.