파이프라인 조건
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
이 문서에서는 Azure Pipelines 단계, 작업 또는 단계가 실행되는 조건 및 다른 조건을 지정하는 방법을 설명합니다. 단계, 작업 및 단계에 대한 자세한 컨텍스트는 Azure Pipelines의 주요 개념을 참조 하세요.
기본적으로 작업 또는 스테이지는 다른 작업이나 스테이지에 종속되지 않거나 모든 종속성이 완료되고 성공했는지에 따라 실행됩니다. 이 요구 사항은 직접 종속성뿐만 아니라 간접 종속성에도 적용되며 재귀적으로 계산됩니다.
기본적으로 해당 작업의 아무 작업도 실패하지 않고 바로 앞에 있는 단계가 완료된 경우 단계가 실행됩니다.
이전 종속성이 실패하더라도 스테이지, 작업 또는 단계를 강제로 실행하거나 사용자 지정 조건을 지정하여 이 동작을 재정의하거나 사용자 지정할 수 있습니다.
참고 항목
이 문서에서는 YAML 파이프라인 기능에 대해 설명합니다. 클래식 파이프라인의 경우 각 태스크의 제어 옵션 및 릴리스 파이프라인의 작업에 대한 추가 옵션에서 작업 또는 작업이 실행되는 일부 조건을 지정할 수 있습니다.
스테이지, 작업 또는 단계가 실행되는 조건
파이프라인 정의 YAML에서 단계, 작업 또는 단계가 실행되는 다음 조건을 지정할 수 있습니다.
동일한 에이전트 풀을 사용하는 이전의 모든 직접 및 간접 종속성이 성공한 경우에만 성공합니다. 다른 에이전트 풀이 있는 경우 해당 단계 또는 작업이 동시에 실행됩니다. YAML에 조건이 설정되지 않은 경우 이 조건은 기본값입니다.
이전 종속성이 실패하더라도 실행이 취소되지 않는 한. 이 조건에 대해 YAML에서 사용합니다
succeededOrFailed().이전 종속성이 실패하고 실행이 취소된 경우에도 이 조건에 대해 YAML에서 사용합니다
always().이전 종속성이 실패하는 경우에만. 이 조건에 대해 YAML에서 사용합니다
failed().
- 사용자 지정 조건.
기본적으로 모든 직접 및 간접 종속성이 성공하면 단계, 작업 및 단계가 실행됩니다. 이 상태는 지정하는 condition: succeeded()것과 같습니다. 자세한 내용은 성공 상태 함수를 참조 하세요.
스테이지, 작업 또는 단계에 대한 속성을 지정 condition 하는 경우 기본값 condition: succeeded()을 덮어쓰게 됩니다. 사용자 고유의 조건을 지정하면 빌드가 취소되더라도 스테이지, 작업 또는 단계가 실행될 수 있습니다. 작성하는 조건이 부모 단계 또는 작업의 상태를 고려해야 합니다.
다음 YAML 예제에서는 조건과 조건을 보여 always() 있습니다 failed() . 첫 번째 작업의 단계는 종속성이 실패하거나 빌드가 취소된 경우에도 실행됩니다. 두 번째 작업은 첫 번째 작업이 실패하는 경우에만 실행됩니다.
jobs:
- job: Foo
steps:
- script: echo Hello!
condition: always() # this step runs, even if the build is canceled
- job: Bar
dependsOn: Foo
condition: failed() # this job runs only if Foo fails
조건에서 변수를 설정하고 사용할 수도 있습니다. 다음 예제에서는 변수를 isMain 설정하고 사용하여 변수를 지정 main 합니다 Build.SourceBranch.
variables:
isMain: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
stages:
- stage: A
jobs:
- job: A1
steps:
- script: echo Hello Stage A!
- stage: B
condition: and(succeeded(), eq(variables.isMain, true))
jobs:
- job: B1
steps:
- script: echo Hello Stage B!
- script: echo $(isMain)
Important
스테이지, 작업 또는 단계를 시작할지 여부를 결정하기 위해 조건이 평가됩니다. 따라서 런타임에 해당 작업 단위 내에서 계산된 것은 없습니다. 예를 들어 구문이 있는 런타임 식을 $[ ] 사용하여 변수를 설정하는 작업이 있는 경우 해당 작업의 사용자 지정 조건에서 해당 변수를 사용할 수 없습니다.
사용자 지정 조건
기본 제공 조건이 요구 사항을 충족하지 않는 경우 사용자 지정 조건을 지정할 수 있습니다. YAML 파이프라인 정의에서 조건을 식으로 작성합니다.
에이전트는 가장 안쪽 함수로 시작하여 바깥쪽으로 진행하는 식을 평가합니다. 최종 결과는 작업, 작업 또는 스테이지를 실행할지 여부를 결정하는 부울 값입니다. 구문에 대한 전체 가이드는 식을 참조 하세요.
빌드가 취소된 후에도 작업을 실행할 수 있는 조건이 있는 경우 사용자가 실행을 취소한 후 이러한 작업을 완료하기에 충분한 시간을 갖도록 취소 시간 제한에 적절한 값을 지정합니다.
빌드가 취소될 때의 조건 결과
빌드를 취소한다고 해서 모든 단계, 작업 또는 단계의 실행이 중지되는 것은 아닙니다. 실행이 중지되는 단계, 작업 또는 단계는 지정한 조건에 따라 달라지며 파이프라인 실행 지점에서 빌드를 취소했습니다. 스테이지, 작업 또는 단계의 부모를 건너뛰면 해당 조건에 관계없이 작업이 실행되지 않습니다.
스테이지, 작업 또는 단계는 해당 조건이 계산될 true때마다 실행됩니다. 조건이 작업의 부모 상태를 고려하지 않는 경우 해당 부모가 취소된 경우에도 작업이 실행될 수 있습니다. 빌드가 취소될 때 조건이 있는 단계, 작업 또는 단계가 실행되는지 여부를 제어하려면 해당 조건에 작업 상태 확인 함수를 포함해야 합니다.
다음 예제에서는 빌드가 취소될 때 단계, 작업 또는 단계에 설정된 다양한 조건의 결과를 보여 줍니다.
스테이지 예제 1
다음 파이프라인에서는 기본적으로 stage2 상태에 관계없이 stage1condition stage2 stage1 원본 분기main가 실행될 때마다 실행할 집합이 있습니다.
분기에서 빌드를 큐에 main 대기하고 실행하는 stage2 동안 stage1 취소하는 경우 < a0/>로 평가되므로 true계속 실행됩니다eq(variables['Build.SourceBranch'], 'refs/heads/main').
stages:
- stage: stage1
jobs:
- job: A
steps:
- script: echo 1; sleep 30
- stage: stage2
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
jobs:
- job: B
steps:
- script: echo 2
스테이지 예제 2
다음 파이프라인 stage2 에서는 기본적으로 의존합니다 stage1 . 작업에 B 집합이 있습니다condition.stage2 분기에서 빌드를 큐에 main 대기하고 실행하는 stage2 동안 stage1 취소하는 경우 조건이 계산true되는 작업이 포함되어 있더라도 실행되지 않습니다.
그 이유는 취소될 때 stage1 계산되는 기본값condition: succeeded()이 false 있기 stage2 때문입니다. 따라서 stage2 건너뛰고 해당 작업이 실행되지 않습니다.
stages:
- stage: stage1
jobs:
- job: A
steps:
- script: echo 1; sleep 30
- stage: stage2
jobs:
- job: B
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
steps:
- script: echo 2
스테이지 예제 3
다음 파이프라인에서 기본적으로 stage2 stage1작업 B 내의 단계에는 집합이 condition 있습니다.
분기에서 빌드를 큐에 main 대기하고 실행하는 stage2 동안 stage1 취소하는 경우 조건이 계산true되는 작업의 B 단계가 포함되어 있더라도 실행되지 않습니다. 그 이유는 취소에 대한 응답으로 건너뛰기 stage1 때문 stage2 입니다.
stages:
- stage: stage1
jobs:
- job: A
steps:
- script: echo 1; sleep 30
- stage: stage2
jobs:
- job: B
steps:
- script: echo 2
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
작업 예제 1
다음 YAML 파이프라인에서 작업은 B 기본적으로 작업에 A 따라 달라지지만, 작업에 B 는 condition 원본 분기가 있을 때마다 실행할 집합이 있습니다 main. 분기에서 빌드를 큐에 main 대기하고 작업이 A 실행되는 동안 취소하는 경우 작업이 B 계속 실행됩니다eq(variables['Build.SourceBranch'], 'refs/heads/main').true
jobs:
- job: A
steps:
- script: sleep 30
- job: B
dependsOn: A
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
steps:
- script: echo step 2.1
작업이 B 성공하고 빌드 원본 main 이 분기 condition 인 경우에만 작업을 A 실행하려면 다음을 수행해야 합니다and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main')).
작업 예제 2
다음 파이프라인에서 작업은 B 기본적으로 작업에 A 따라 달라집니다. 분기에서 빌드를 큐에 main 대기하고 작업이 A 실행되는 동안 취소하면 해당 단계에 계산true되는 작업이 condition 있더라도 작업이 B 실행되지 않습니다.
그 이유는 작업이 B 취소될 때 계산되는 기본값 condition: succeeded()이 false 작업에 A 있기 때문입니다. 따라서 작업을 B 건너뛰고 해당 단계가 실행되지 않습니다.
jobs:
- job: A
steps:
- script: sleep 30
- job: B
dependsOn: A
steps:
- script: echo step 2.1
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main', succeeded())
단계 예제
단계에 대한 조건을 가질 수도 있습니다.
다음 파이프라인에서 2.3단계에는 condition 원본 분기가 있을 때마다 실행할 집합이 있습니다 main. 분기에서 빌드를 큐에 main 대기하고 2.1 또는 2.2 단계가 실행되는 동안 취소하는 경우 2.3단계는 계산되므로 true계속 실행됩니다eq(variables['Build.SourceBranch'], 'refs/heads/main').
steps:
- script: echo step 2.1
- script: echo step 2.2; sleep 30
- script: echo step 2.3
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
조건 설정
다음 표에서는 다양한 결과를 생성하는 예제 condition 설정을 보여 줍니다.
참고 항목
Release.Artifacts.{artifact-alias}.SourceBranch는 Build.SourceBranch와 같습니다.
| 원하는 결과 | 조건 설정 예제 |
|---|---|
| 부모 또는 이전 단계, 작업 또는 단계가 실패했거나 취소된 경우에도 원본 분기가 기본인 경우 실행합니다. | eq(variables['Build.SourceBranch'], 'refs/heads/main') |
| 원본 분기가 주 분기이고 부모 또는 이전 단계, 작업 또는 단계가 성공한 경우 실행합니다. | and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main')) |
| 원본 분기가 기본이 아니고 부모 또는 이전 단계, 작업 또는 단계가 성공하면 실행합니다. | and(succeeded(), ne(variables['Build.SourceBranch'], 'refs/heads/main')) |
| 부모 또는 이전 단계, 작업 또는 단계가 성공한 경우 사용자 토픽 분기에 대해 실행합니다. | and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/heads/users/')) |
| 부모 또는 이전 단계, 작업 또는 단계가 성공한 경우 CI(연속 통합) 빌드를 위해 실행합니다. | and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI')) |
| 끌어오기 요청에 대한 분기 정책에 의해 빌드가 트리거되고 부모 또는 이전 단계, 작업 또는 단계가 실패한 경우 실행합니다. | and(failed(), eq(variables['Build.Reason'], 'PullRequest')) |
| 부모 또는 이전 단계, 작업 또는 단계가 실패했거나 취소된 경우에도 예약된 빌드에 대해 실행합니다. | eq(variables['Build.Reason'], 'Schedule') |
| 부모 또는 이전 단계, 작업 또는 단계가 실패했거나 취소된 경우에도 변수가 true로 설정된 경우 실행합니다. | eq(variables['System.debug'], true) |
참고 항목
변수가 null(빈 문자열)인 경우 실행할 조건을 설정할 수 있습니다. 모든 변수는 Azure Pipelines에서 문자열로 처리되므로 빈 문자열은 다음 파이프라인과 동일합니다 null .
variables:
- name: testEmpty
value: ''
jobs:
- job: A
steps:
- script: echo testEmpty is blank
condition: eq(variables.testEmpty, '')
조건의 매개 변수
매개 변수 확장은 조건을 고려하기 전에 발생합니다. 따라서 조건과 동일한 파이프라인에서 매개 변수를 선언하는 경우 조건 내에 매개 변수를 포함할 수 있습니다. 다음 YAML의 스크립트는 true이므로 실행됩니다 parameters.doThing .
parameters:
- name: doThing
default: true
type: boolean
steps:
- script: echo I did a thing
condition: and(succeeded(), ${{ eq(parameters.doThing, true) }})
condition 이전 파이프라인의 두 함수는 다음과 같은 두 가지 함수를 결합합니다 succeeded() ${{ eq(parameters.doThing, true) }}. 함수는 succeeded() 이전 단계가 성공했는지 확인합니다. succeeded() 이전 단계가 없으므로 함수가 반환 true 됩니다.
함수는 ${{ eq(parameters.doThing, true) }} 매개 변수가 같 doThing 는지 여부를 확인합니다 true. 기본값은 true파이프라인이 다른 값을 doThing 설정하지 않는 한 기본적으로 반환 true 됩니다.
조건의 템플릿 매개 변수
템플릿에 매개 변수를 전달하는 경우 템플릿에서 매개 변수 값을 설정하거나 templateContext를 사용하여 매개 변수를 템플릿에 전달해야 합니다.
예를 들어 다음 parameters.yml 파일은 매개 변수와 기본값을 doThing 선언합니다.
# parameters.yml
parameters:
- name: doThing
default: true # value passed to the condition
type: boolean
jobs:
- job: B
steps:
- script: echo I did a thing
condition: ${{ eq(parameters.doThing, true) }}
파이프라인 코드는 parameters.yml 템플릿을 참조합니다. 파이프라인의 출력은 I did a thing 매개 변수 doThing 가 true이기 때문입니다.
# azure-pipeline.yml
parameters:
- name: doThing
default: true
type: boolean
trigger:
- none
extends:
template: parameters.yml
더 많은 템플릿 매개 변수 예제는 템플릿 사용 참조를 참조하세요.
후속 작업 조건에서 사용되는 작업 출력 변수
변수를 향후 작업에 사용할 수 있도록 하고 조건에 지정할 수 있습니다. 이후 작업에 사용할 수 있는 변수는 다음 코드와 같이 다중 작업 출력 변수isOutput=true로 표시되어야 합니다.
jobs:
- job: Foo
steps:
- bash: |
echo "This is job Foo."
echo "##vso[task.setvariable variable=doThing;isOutput=true]Yes" #set variable doThing to Yes
name: DetermineResult
- job: Bar
dependsOn: Foo
condition: eq(dependencies.Foo.outputs['DetermineResult.doThing'], 'Yes') #map doThing and check the value
steps:
- script: echo "Job Foo ran and doThing is Yes."
후속 단계 조건에서 사용되는 단계에서 만든 변수
이후 단계에서 조건에 지정할 수 있는 변수를 만들 수 있습니다. 단계에서 만든 변수는 기본적으로 이후 단계에서 사용할 수 있으며 다중 작업 출력 변수로 표시할 필요가 없습니다.
단계에서 만든 변수 범위 지정에 대해 유의해야 할 몇 가지 중요한 사항이 있습니다.
- 작업의 단계에서 만든 변수는 동일한 작업의 단계로 범위가 지정됩니다.
- 한 단계에서 만든 변수는 환경 변수로만 후속 단계에서 사용할 수 있습니다.
- 단계에서 만든 변수는 이를 정의하는 단계에서 사용할 수 없습니다.
다음 예제에서는 단계에서 파이프라인 변수를 만들고 후속 단계의 조건 및 스크립트에서 변수를 사용하는 방법을 보여 있습니다.
steps:
# This step creates a new pipeline variable: doThing. This variable is available to subsequent steps.
- bash: |
echo "##vso[task.setvariable variable=doThing]Yes"
displayName: Step 1
# This step is able to use doThing, so it uses doThing in its condition
- script: |
# Access the variable from Step 1 as an environment variable.
echo "Value of doThing (as DOTHING env var): $DOTHING."
displayName: Step 2
condition: and(succeeded(), eq(variables['doThing'], 'Yes')) # or and(succeeded(), eq(variables.doThing, 'Yes'))
FAQ
이전 작업에 문제가 있는 경우 작업을 트리거하려면 어떻게 해야 하나요?
이전 작업의 결과를 조건에서 사용할 수 있습니다. 예를 들어 다음 YAML에서는 문제가 있는 작업이 B 성공했기 때문에 이 조건을 eq(dependencies.A.result,'SucceededWithIssues') 통해 작업을 A 실행할 수 있습니다.
jobs:
- job: A
displayName: Job A
continueOnError: true # next job starts even if this one fails
steps:
- script: echo Job A ran
- script: exit 1
- job: B
dependsOn: A
condition: eq(dependencies.A.result,'SucceededWithIssues') # targets the result of the previous job
displayName: Job B
steps:
- script: echo Job B ran
빌드를 취소했지만 여전히 실행 중입니다. 이유는 무엇입니까?
단계에서 구성된 조건에 작업 상태 확인 함수가 포함되지 않은 경우 이 문제가 발생할 수 있습니다. 이 문제를 해결하려면 조건에 작업 상태 검사 함수를 추가합니다.
큐 단계에 있지만 실행되지 않는 동안 작업을 취소하면 다른 모든 단계를 포함하여 전체 작업이 취소됩니다. 자세한 내용은 이 문서의 앞부분에서 빌드가 취소될 때의 조건 결과를 참조하세요.