Bitbucket Cloud 리포지토리 빌드

아티클
10/27/2023

Azure DevOps Services

Azure Pipelines는 모든 끌어오기 요청을 자동으로 빌드하고 유효성을 검사하고 Bitbucket Cloud 리포지토리에 커밋할 수 있습니다. 이 문서에서는 Bitbucket Cloud와 Azure Pipelines 간의 통합을 구성하는 방법을 설명합니다.

Bitbucket과 Azure Pipelines는 서로 잘 통합되는 두 개의 독립적인 서비스입니다. Bitbucket 클라우드 사용자는 Azure Pipelines에 자동으로 액세스하지 않습니다. Azure Pipelines에 명시적으로 추가해야 합니다.

먼저 Bitbucket Cloud 리포지토리를 선택한 다음 해당 리포지토리에서 YAML 파일을 선택하여 새 파이프라인을 만듭니다. YAML 파일이 있는 리포지토리를 리포지토리라고 합니다 self . 기본적으로 파이프라인이 빌드하는 리포지토리입니다.

나중에 다른 리포지토리 또는 여러 리포지토리를 검사 파이프라인을 구성할 수 있습니다. 이 작업을 수행하는 방법을 알아보려면 다중 리포지토리 검사out을 참조하세요.

빌드하는 동안 코드를 가져오려면 리포지토리에 대한 액세스 권한을 Azure Pipelines에 부여해야 합니다. 또한 파이프라인을 설정하는 사용자는 Bitbucket에 웹후크를 등록하는 데 해당 ID를 사용하므로 Bitbucket에 대한 관리자 액세스 권한이 있어야 합니다.

파이프라인을 만드는 동안 Azure Pipelines에 Bitbucket Cloud 리포지토리에 대한 액세스 권한을 부여하기 위한 두 가지 인증 유형이 있습니다.

Authentication type	파이프라인을 사용하여 실행
1. OAuth	개인 Bitbucket ID
2. 사용자 이름 및 암호	개인 Bitbucket ID

OAuth 인증

OAuth는 Bitbucket 계정의 리포지토리에 대해 시작하는 가장 간단한 인증 유형입니다. Bitbucket 상태 업데이트는 개인 Bitbucket ID를 대신하여 수행됩니다. 파이프라인이 계속 작동하려면 리포지토리 액세스가 다시 활성화되어야 기본.

OAuth를 사용하려면 파이프라인을 만드는 동안 메시지가 표시되면 Bitbucket에 로그인합니다. 그런 다음 권한 부여를 클릭하여 OAuth로 권한을 부여합니다. OAuth 연결은 나중에 사용할 수 있을 뿐만 아니라 생성되는 파이프라인에서 사용할 수 있게 Azure DevOps 프로젝트에 저장됩니다.

참고 항목

Azure DevOps Services 사용자 인터페이스에서 로드할 수 있는 Bitbucket 리포지토리의 최대 수는 2,000개입니다.

암호 인증

빌드 및 Bitbucket 상태 업데이트는 개인 ID를 대신하여 수행됩니다. 빌드가 계속 작동하려면 리포지토리 액세스가 다시 활성화되어야 기본.

암호 연결을 만들려면 Azure DevOps 프로젝트 설정에서 서비스 연결을 방문합니다. 새 Bitbucket 서비스 연결을 만들고 사용자 이름과 암호를 제공하여 Bitbucket Cloud 리포지토리에 연결합니다.

CI 트리거

CI(연속 통합) 트리거는 지정된 분기에 업데이트를 푸시하거나 지정된 태그를 푸시할 때마다 파이프라인을 실행합니다.

YAML
클래식

YAML 파이프라인은 Azure DevOps 스프린트 227에 도입된 암시적 YAML CI 트리거 설정 사용 안 함을 사용하지 않는 한 모든 분기에서 CI 트리거를 사용하여 기본적으로 구성됩니다. 암시적 YAML CI 트리거 사용 안 함 설정은 조직 수준 또는 프로젝트 수준에서 구성할 수 있습니다. 암시적 YAML CI 트리거 설정 사용 안 함을 사용하면 YAML 파이프라인에 섹션이 없는 trigger 경우 YAML 파이프라인에 대한 CI 트리거가 활성화되지 않습니다. 기본적으로 암시적 YAML CI 트리거 를 사용하지 않도록 설정하지 않습니다.

분기

간단한 구문을 사용하여 CI 트리거를 가져오는 분기를 제어할 수 있습니다.

trigger:
- main
- releases/*

분기의 전체 이름(예: main)을 지정하거나 wild카드(예: releases/*)를 지정할 수 있습니다. wild카드 구문에 대한 자세한 내용은 카드 참조하세요.

참고 항목

트리거가 발생한 후 런타임에 변수가 평가되므로 트리거에는 변수를 사용할 수 없습니다.

참고 항목

템플릿을 사용하여 YAML 파일을 작성하는 경우 파이프라인에 대한 기본 YAML 파일에서만 트리거를 지정할 수 있습니다. 템플릿 파일에서 트리거를 지정할 수 없습니다.

사용하거나 batch사용하는 더 복잡한 트리거 exclude 의 경우 다음 예제와 같이 전체 구문을 사용해야 합니다.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

위의 예제에서 변경 내용이 릴리스 분기로 푸시되거나 릴리스 분기로 main 푸시되면 파이프라인이 트리거됩니다. 그러나 .로 시작하는 old릴리스 분기가 변경되면 트리거되지 않습니다.

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

목록에서 분기 이름을 branches 지정하는 것 외에도 다음 형식을 사용하여 태그를 기반으로 트리거를 구성할 수도 있습니다.

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

트리거를 지정하지 않았고 암시적 YAML CI 트리거 사용 안 함 설정을 사용하도록 설정하지 않은 경우 기본값은 다음과 같습니다.

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Important

트리거를 지정하면 기본 암시적 트리거가 대체되고 포함되도록 명시적으로 구성된 분기에만 푸시하면 파이프라인이 트리거됩니다. 포함은 먼저 처리된 다음 제외는 해당 목록에서 제거됩니다.

CI 실행 일괄 처리

변경 내용을 자주 업로드하는 팀 구성원이 많은 경우 시작하는 실행 수를 줄일 수 있습니다. 파이프라인이 실행 중일 때 실행이 완료될 때까지 대기한 다음 아직 빌드되지 않은 모든 변경 내용으로 다른 실행을 시작하도록 true설정하는 batch 경우

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

참고 항목

batch 는 리포지토리 리소스 트리거에서 지원되지 않습니다.

이 예제를 명확히 하기 위해 위의 파이프라인을 실행하도록 main 푸시 A 했다고 가정해 보겠습니다. 해당 파이프라인이 실행되는 동안 추가 푸시가 B C 리포지토리에 발생합니다. 이러한 업데이트는 새 독립 실행을 즉시 시작하지 않습니다. 그러나 첫 번째 실행이 완료되면 해당 시점이 함께 일괄 처리되고 새 실행이 시작될 때까지 모든 푸시가 수행됩니다.

참고 항목

파이프라인에 여러 작업 및 단계가 있는 경우 첫 번째 실행은 두 번째 실행을 시작하기 전에 모든 작업 및 단계를 완료하거나 건너뛰어 터미널 상태에 도달해야 합니다. 이러한 이유로 여러 단계 또는 승인이 있는 파이프라인에서 이 기능을 사용할 때는 주의해야 합니다. 이러한 경우 빌드를 일괄 처리하려는 경우 CI/CD 프로세스를 빌드용(일괄 처리 포함) 및 배포용 파이프라인의 두 파이프라인으로 분할하는 것이 좋습니다.

경로

포함하거나 제외할 파일 경로를 지정할 수 있습니다.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

경로를 지정할 때 Azure DevOps Server 2019.1 이하를 사용하는 경우 트리거할 분기를 명시적으로 지정해야 합니다. 경로 필터만 사용하여 파이프라인을 트리거할 수 없습니다. 또한 분기 필터가 있어야 하며 경로 필터와 일치하는 변경된 파일은 분기 필터와 일치하는 분기에서 온 것이어야 합니다. Azure DevOps Server 2020 이상에서 사용하는 경우 경로 필터와 함께 모든 분기에서 필터링을 생략 branches 할 수 있습니다.

Wilds 카드 경로 필터에 대해 지원됩니다. 예를 들어 일치하는 src/app/**/myapp*모든 경로를 포함할 수 있습니다. 야생 카드 문자(***또는 ?) 경로 필터를 지정할 때)를 사용할 수 있습니다.

경로는 항상 리포지토리의 루트를 기준으로 지정됩니다.
경로 필터를 설정하지 않으면 리포지토리의 루트 폴더가 기본적으로 암시적으로 포함됩니다.
경로를 제외하는 경우 더 깊은 폴더로 한정하지 않으면 경로를 포함할 수 없습니다. 예를 들어 /tools를 제외하면 /tools/trigger-runs-on-these를 포함할 수 있습니다.
경로 필터의 순서는 중요하지 않습니다.
Git 의 경로는 대/소문자를 구분합니다. 실제 폴더와 동일한 사례를 사용해야 합니다.
트리거가 발생한 후 런타임에 변수가 평가되므로 경로에 변수를 사용할 수 없습니다.

참고 항목

Bitbucket Cloud 리포지토리의 경우 구문을 사용하는 branches 것이 태그 트리거를 지정하는 유일한 방법입니다. tags: Bitbucket에는 구문이 지원되지 않습니다.

CI 옵트아웃

CI 트리거를 사용하지 않도록 설정

를 지정하여 CI 트리거를 완전히 옵트아웃할 수 있습니다 trigger: none.

# A pipeline with no CI trigger
trigger: none

Important

분기로 변경 사항을 푸시하면 해당 분기의 YAML 파일이 평가되어 CI 실행을 시작해야 하는지 확인합니다.

참고 항목

빌드가 진행 중인 동안 Batch가 변경되면 Build.SourceVersionMessage 변수가 Bitbucket 리포지토리에서 작동하지 않습니다.

코드에서 누군가가 검사 때마다 빌드를 실행하려면 트리거 탭에서 연속 통합 사용을 선택하여 이 트리거를 사용하도록 설정합니다.

일괄 처리 변경 내용

변경 내용을 자주 업로드하는 팀 구성원이 많고 실행 중인 빌드 수를 줄이려면 이 검사 상자를 선택합니다. 이 옵션을 선택하면 빌드가 실행될 때 시스템이 실행이 완료될 때까지 기다린 다음 아직 빌드되지 않은 모든 변경 내용의 또 다른 실행을 큐에 대기합니다.

변경 내용을 일괄 처리하고 함께 빌드할 수 있습니다.

참고 항목

다단계 YAML 파이프라인에서 일괄 처리를 사용하는 경우 다음 단계를 시작하기 전에 실행이 터미널 상태에 도달해야 합니다. 다단계 파이프라인이 승인 및 장기 실행 배포 단계를 통과할 수 있으므로 이는 바람직하지 않은 경우가 많습니다. 이러한 경우 다음 솔루션 중 하나를 따르는 것이 좋습니다.

일괄 처리를 사용하지 마세요.
파이프라인을 두 개의 개별 파이프라인(CI용 및 CD용)으로 분할
스테이지에서 적절한 조건을 설정하여 건너뛰고 실행이 신속하게 종료되도록 합니다.

분기 필터

빌드를 트리거할 분기를 지정할 수 있습니다. wild카드 문자를 사용하려면 분기 사양(예features/modules/*: )을 입력한 다음 Enter 키를 누릅니다.

패스 필터

Git 리포지토리가 Azure Repos 또는 TFS에 있는 경우 경로 필터를 지정하여 빌드를 트리거하려는 파일 집합을 줄일 수도 있습니다.

팁:

경로는 항상 리포지토리의 루트를 기준으로 지정됩니다.

경로 필터를 설정하지 않으면 리포지토리의 루트 폴더가 기본적으로 암시적으로 포함됩니다.

경로를 제외하는 경우 더 깊은 폴더로 한정하지 않으면 경로를 포함할 수 없습니다. 예를 들어 /tools를 제외하면 /tools/trigger-runs-on-these를 포함할 수 있습니다.

경로 필터의 순서는 중요하지 않습니다.

Git의 경로는 대/소문자를 구분합니다. 실제 폴더와 동일한 사례를 사용해야 합니다.

예시

예를 들어 기능 분기 변경 main 내용에 의해 빌드가 트리거되도록 할 수 있습니다. 또한 도구 폴더의 파일 변경으로 인해 빌드가 트리거되지 않도록 합니다.

ci trigger git branches

개별 커밋에 대한 CI 건너뛰기

푸시가 일반적으로 트리거되는 파이프라인 실행을 건너뛰도록 Azure Pipelines에 지시할 수도 있습니다. 푸시의 일부인 커밋에 대한 메시지 또는 설명에 포함 [skip ci] 하기만 하면 Azure Pipelines는 이 푸시에 대한 CI 실행을 건너뜁니다. 다음과 같은 변형을 사용할 수도 있습니다.

[skip ci] 또는 [ci skip]
skip-checks: true 또는 skip-checks:true
[skip azurepipelines] 또는 [azurepipelines skip]
[skip azpipelines] 또는 [azpipelines skip]
[skip azp] 또는 [azp skip]
***NO_CI***

조건에서 트리거 유형 사용

실행을 시작한 트리거 유형에 따라 파이프라인에서 다른 단계, 작업 또는 단계를 실행하는 것이 일반적인 시나리오입니다. 시스템 변수 Build.Reason를 사용하여 이 작업을 수행할 수 있습니다. 예를 들어 다음 조건을 단계, 작업 또는 단계에 추가하여 PR 유효성 검사에서 제외합니다.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

새 분기를 만들 때 트리거의 동작

동일한 리포지토리에 대해 여러 파이프라인을 구성하는 것이 일반적입니다. 예를 들어 앱에 대한 문서를 빌드하는 파이프라인 하나와 소스 코드를 빌드하는 파이프라인이 있을 수 있습니다. 이러한 각 파이프라인에서 적절한 분기 필터 및 경로 필터를 사용하여 CI 트리거를 구성할 수 있습니다. 예를 들어 폴더에 업데이트를 푸시할 때 하나의 파이프라인이 트리거되고, 애플리케이션 코드에 docs 업데이트를 푸시할 때 다른 파이프라인이 트리거되도록 할 수 있습니다. 이러한 경우 새 분기를 만들 때 파이프라인이 트리거되는 방식을 이해해야 합니다.

다음은 새 분기(분기 필터와 일치)를 리포지토리에 푸시할 때의 동작입니다.

파이프라인에 경로 필터가 있는 경우 새 분기에 해당 경로 필터와 일치하는 파일이 변경된 경우에만 트리거됩니다.
파이프라인에 경로 필터가 없는 경우 새 분기에 변경 내용이 없더라도 트리거됩니다.

와일드카드

분기, 태그 또는 경로를 지정할 때 정확한 이름 또는 wild카드 사용할 수 있습니다. 와일드카드 패턴은 0개 이상의 문자를 일치시키고 ? 단일 문자를 일치시킬 수 있습니다*.

YAML 파이프라인에서 패턴을 * 시작하는 경우 다음과 같이 "*-releases"패턴을 따옴표로 래핑해야 합니다.
분기 및 태그의 경우:
- 야생카드 패턴의 아무 곳에나 나타날 수 있습니다.
경로의 경우:
- Azure DevOps Services를 포함하여 Azure DevOps Server 2022 이상에서는 야생카드 경로 패턴 내의 아무 곳에나 나타날 수 있으며 사용하거나 ?사용할 * 수 있습니다.
- Azure DevOps Server 2020 이하에서는 최종 문자로 포함 * 할 수 있지만 디렉터리 이름 자체를 지정하는 것과 다르게 수행되지는 않습니다. 경로 필터의 중간에 포함되지 * 않을 수 있으며 사용하지 ?않을 수 있습니다.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR 트리거

PR(끌어오기 요청) 트리거는 지정된 대상 분기 중 하나를 사용하여 끌어오기 요청을 열거나 이러한 끌어오기 요청에 대한 업데이트가 수행될 때마다 파이프라인을 실행합니다.

YAML
클래식

분기

끌어오기 요청의 유효성을 검사할 때 대상 분기를 지정할 수 있습니다. 예를 들어 대상 master releases/*인 끌어오기 요청의 유효성을 검사하려면 다음 pr 트리거를 사용할 수 있습니다.

pr:
- main
- releases/*

이 구성은 새 끌어오기 요청이 처음 생성되고 끌어오기 요청을 업데이트할 때마다 새 실행을 시작합니다.

분기의 전체 이름(예: master)을 지정하거나 wild카드(예: releases/*)를 지정할 수 있습니다.

참고 항목

트리거가 발생한 후 런타임에 변수가 평가되므로 트리거에는 변수를 사용할 수 없습니다.

참고 항목

각 새 실행은 끌어오기 요청의 원본 분기에서 최신 커밋을 빌드합니다. 이는 Azure Pipelines가 병합 커밋을 빌드하는 다른 리포지토리(예: Azure Repos 또는 GitHub)에서 끌어오기 요청을 빌드하는 방법과 다릅니다. 안타깝게도 Bitbucket은 끌어오기 요청의 원본 분기와 대상 분기 간에 병합된 코드를 포함하는 병합 커밋에 대한 정보를 노출하지 않습니다.

YAML 파일에 트리거가 표시되지 않으면 pr 다음 pr 트리거를 작성한 것처럼 모든 분기에 대해 끌어오기 요청 유효성 검사가 자동으로 활성화됩니다. 이 구성은 끌어오기 요청이 만들어지고 커밋이 활성 끌어오기 요청의 원본 분기에 들어올 때 빌드를 트리거합니다.

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Important

트리거를 pr 지정하면 기본 암시적 pr 트리거가 대체되고 포함되도록 명시적으로 구성된 분기에만 푸시하면 파이프라인이 트리거됩니다.

특정 분기를 제외해야 하는 더 복잡한 트리거의 경우 다음 예제와 같이 전체 구문을 사용해야 합니다.

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

경로

포함하거나 제외할 파일 경로를 지정할 수 있습니다. 예시:

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

팁:

와일드 카드 경로 필터에서는 지원되지 않습니다.

경로는 항상 리포지토리의 루트를 기준으로 지정됩니다.

경로 필터를 설정하지 않으면 리포지토리의 루트 폴더가 기본적으로 암시적으로 포함됩니다.

경로를 제외하는 경우 더 깊은 폴더로 한정하지 않으면 경로를 포함할 수 없습니다. 예를 들어 /tools를 제외하면 /tools/trigger-runs-on-these를 포함할 수 있습니다.

경로 필터의 순서는 중요하지 않습니다.

Git 의 경로는 대/소문자를 구분합니다. 실제 폴더와 동일한 사례를 사용해야 합니다.

트리거가 발생한 후 런타임에 변수가 평가되므로 경로에 변수를 사용할 수 없습니다.

여러 PR 업데이트

PR에 대한 추가 업데이트가 동일한 PR에 대해 진행 중인 유효성 검사 실행을 취소할지 여부를 지정할 수 있습니다. 기본값은 true입니다.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

PR 유효성 검사 옵트아웃

를 지정하여 끌어오기 요청 유효성 검사를 완전히 옵트아웃할 수 있습니다 pr: none.

# no PR triggers
pr: none

자세한 내용은 YAML 스키마의 PR 트리거 를 참조하세요.

참고 항목

pr 트리거가 실행되지 않는 경우 UI에서 YAML PR 트리거를 재정의하지 않았는지 확인합니다.

정보 실행

정보 실행은 Azure DevOps가 YAML 파이프라인의 소스 코드를 검색하지 못했음을 알려줍니다. 소스 코드 검색은 외부 이벤트(예: 푸시된 커밋)에 대한 응답으로 발생합니다. 예를 들어 코드 변경 내용이 있는 경우 검사 예약된 실행을 시작하는 등 내부 트리거에 대한 응답으로도 발생합니다. 소스 코드 검색은 여러 가지 이유로 실패할 수 있으며, git 리포지토리 공급자가 자주 요청을 제한합니다. 정보 실행이 있다고 해서 반드시 Azure DevOps가 파이프라인을 실행한다는 의미는 아닙니다.

정보 실행은 다음 스크린샷과 같습니다.

Screenshot of an informational pipeline run.

다음 특성으로 정보 실행을 인식할 수 있습니다.

상태가 Canceled
기간은 < 1s
실행 이름에는 다음 텍스트 중 하나가 포함됩니다.
- Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
- Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
- Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
- Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
실행 이름에는 일반적으로 YAML 파이프라인 로드가 실패하게 한 BitBucket/GitHub 오류가 포함됩니다.
단계 없음 / 작업 / 단계

정보 실행에 대해 자세히 알아봅니다.

제한 사항

Azure Pipelines는 리포지토리에서 Azure Devops 포털의 드롭다운 목록으로 최대 2,000개의 분기를 로드합니다( 예 : 수동 및 예약된 빌드 설정을 위한 기본 분기로 또는 파이프라인을 수동으로 실행할 때 분기를 선택할 때). 목록에 원하는 분기가 표시되지 않으면 원하는 분기 이름을 수동으로 입력합니다.

FAQ

Bitbucket 통합과 관련된 문제는 다음 범주로 나타낸다.

실패 트리거: 리포지토리에 업데이트를 푸시할 때 파이프라인이 트리거되지 않습니다.
잘못된 버전: 내 파이프라인이 실행되지만 예기치 않은 버전의 원본/YAML을 사용하고 있습니다.

실패한 트리거

CI/PR 트리거를 사용하여 새 YAML 파이프라인을 만들었지만 파이프라인은 트리거되지 않습니다.

다음 각 단계에 따라 실패한 트리거 문제를 해결합니다.

YAML CI 또는 PR 트리거가 UI의 파이프라인 설정에 의해 재정의되고 있나요? 파이프라인을 편집하는 동안 ...를 선택한 다음 트리거합니다.

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

웹후크는 Bitbucket에서 Azure Pipelines로 업데이트를 전달하는 데 사용됩니다. Bitbucket에서 리포지토리의 설정으로 이동한 다음 웹후크로 이동합니다. 웹후크가 있는지 확인합니다.

파이프라인이 일시 중지되거나 비활성화되어 있나요? 파이프라인에 대한 편집기를 연 다음 설정 선택하여 검사. 파이프라인이 일시 중지되거나 비활성화된 경우 트리거가 작동하지 않습니다.
올바른 분기에서 YAML 파일을 업데이트했나요? 분기로 업데이트를 푸시하는 경우 동일한 분기의 YAML 파일이 CI 동작을 제어합니다. 원본 분기에 업데이트를 푸시하는 경우 원본 분기를 대상 분기와 병합하여 발생하는 YAML 파일이 PR 동작을 제어합니다. 올바른 분기의 YAML 파일에 필요한 CI 또는 PR 구성이 있는지 확인합니다.
트리거를 올바르게 구성했나요? YAML 트리거를 정의할 때 분기, 태그 및 경로에 대한 include 및 exclude 절을 모두 지정할 수 있습니다. include 절이 커밋의 세부 정보와 일치하고 제외 절에서 제외하지 않는지 확인합니다. 트리거의 구문을 확인하고 정확한지 확인합니다.
트리거 또는 경로를 정의하는 데 변수를 사용했나요? 이는 지원되지 않습니다.
YAML 파일에 템플릿을 사용했나요? 그렇다면 트리거가 기본 YAML 파일에 정의되어 있는지 확인합니다. 템플릿 파일 내에 정의된 트리거는 지원되지 않습니다.
변경 내용을 푸시한 분기 또는 경로를 제외했나요? 포함된 분기의 포함된 경로로 변경한 항목을 푸시하여 테스트합니다. 트리거의 경로는 대/소문자를 구분합니다. 트리거에서 경로를 지정할 때 실제 폴더의 사례와 동일한 경우를 사용해야 합니다.
새 분기를 푸시했나요? 이 경우 새 분기가 새 실행을 시작하지 않을 수 있습니다. "새 분기를 만들 때 트리거의 동작" 섹션을 참조하세요.

CI 또는 PR 트리거가 정상적으로 작동했습니다. 그러나, 그들은 지금 일을 중단.

먼저 이전 질문의 문제 해결 단계를 진행합니다. 그런 다음, 다음 추가 단계를 수행합니다.

PR에 병합 충돌 있나요? 파이프라인을 트리거하지 않은 PR의 경우 파이프라인을 열고 병합 충돌 있는지 여부를 검사. 병합 충돌 해결합니다.
푸시 또는 PR 이벤트 처리가 지연되나요? 일반적으로 문제가 단일 파이프라인과 관련이 있는지 또는 프로젝트의 모든 파이프라인 또는 리포지토리에 공통적인지 확인하여 이를 확인할 수 있습니다. 리포지토리에 대한 푸시 또는 PR 업데이트가 이러한 증상을 보이는 경우 업데이트 이벤트 처리가 지연될 수 있습니다. 상태 페이지에서 서비스 중단이 발생하는지 확인합니다. 상태 페이지에 문제가 표시되면 우리 팀은 이미 문제를 해결하기 시작했어야 합니다. 이 문제에 대한 업데이트는 페이지를 자주 확인하세요.

사용자가 YAML 파일을 업데이트할 때 트리거에 대한 분기 목록을 재정의하지 않도록 합니다. 어떻게 하면 되나요?

코드를 기여할 수 있는 권한이 있는 사용자는 YAML 파일을 업데이트하고 추가 분기를 포함/제외할 수 있습니다. 따라서 사용자는 YAML 파일에 자신의 기능 또는 사용자 분기를 포함하고 해당 업데이트를 기능 또는 사용자 분기에 푸시할 수 있습니다. 이로 인해 해당 분기에 대한 모든 업데이트에 대해 파이프라인이 트리거될 수 있습니다. 이 동작을 방지하려면 다음을 수행할 수 있습니다.

Azure Pipelines UI에서 파이프라인을 편집합니다.
트리거 메뉴로 이동합니다.
여기에서 YAML 연속 통합 트리거 재정의를 선택합니다.
트리거에 포함하거나 제외할 분기를 지정합니다.

이러한 단계를 수행하면 YAML 파일에 지정된 모든 CI 트리거가 무시됩니다.

잘못된 버전

파이프라인에서 잘못된 버전의 YAML 파일이 사용되고 있습니다. 왜 그럴까요?

CI 트리거의 경우 푸시하는 분기에 있는 YAML 파일을 평가하여 CI 빌드를 실행해야 하는지 확인합니다.
PR 트리거의 경우 PR의 원본 및 대상 분기를 병합하여 발생하는 YAML 파일을 평가하여 PR 빌드를 실행해야 하는지 확인합니다.

다음을 통해 공유

Bitbucket Cloud 리포지토리 빌드

Bitbucket 리포지토리에 대한 액세스 권한

OAuth 인증

암호 인증

CI 트리거

분기

CI 실행 일괄 처리

경로

CI 옵트아웃

CI 트리거를 사용하지 않도록 설정

일괄 처리 변경 내용

분기 필터

패스 필터

예시

개별 커밋에 대한 CI 건너뛰기

조건에서 트리거 유형 사용

새 분기를 만들 때 트리거의 동작

와일드카드

PR 트리거

분기

경로

여러 PR 업데이트

PR 유효성 검사 옵트아웃

정보 실행

제한 사항

FAQ

실패한 트리거

CI/PR 트리거를 사용하여 새 YAML 파이프라인을 만들었지만 파이프라인은 트리거되지 않습니다.

CI 또는 PR 트리거가 정상적으로 작동했습니다. 그러나, 그들은 지금 일을 중단.

사용자가 YAML 파일을 업데이트할 때 트리거에 대한 분기 목록을 재정의하지 않도록 합니다. 어떻게 하면 되나요?

잘못된 버전

파이프라인에서 잘못된 버전의 YAML 파일이 사용되고 있습니다. 왜 그럴까요?

피드백

추가 리소스