조건 지정

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

각 단계, 작업 또는 단계가 실행되는 조건을 지정할 수 있습니다. 기본적으로 작업 또는 스테이지는 다른 작업이나 단계에 의존하지 않거나 작업 또는 스테이지가 의존하는 모든 작업이 완료되고 성공했는지 여부에 따라 실행됩니다. 여기에는 직접 종속성뿐만 아니라 해당 종속성도 재귀적으로 계산됩니다. 기본적으로 작업에서 아직 실패한 것이 없고 직전 단계가 완료된 경우 단계가 실행됩니다. 이전 종속성이 실패하더라도 강제로 단계, 작업 또는 단계를 실행하거나 사용자 지정 조건을 지정하여 이 동작을 사용자 지정할 수 있습니다.

단계, 작업 또는 단계가 실행될 조건을 지정할 수 있습니다.

  • 동일한 에이전트 풀을 사용하는 이전의 모든 직접 및 간접 종속성이 성공한 경우에만 가능합니다. 다른 에이전트 풀이 있는 경우 해당 단계 또는 작업이 동시에 실행됩니다. YAML에 설정된 조건이 없는 경우 기본값입니다.

  • 이전 종속성이 실패한 경우에도 실행이 취소되지 않은 경우 이 조건에 대해 YAML에서 사용합니다 succeededOrFailed() .

  • 이전 종속성이 실패하고 실행이 취소된 경우에도 이 조건에 대해 YAML에서 사용합니다 always() .

  • 이전 종속성이 실패한 경우에만 이 조건에 대해 YAML에서 사용합니다 failed() .

  • 사용자 지정 조건

기본적으로 단계, 작업 및 단계는 모든 직접 및 간접 종속성이 성공한 경우 실행됩니다. 마치 "condition: succeeded()"를 지정한 것과 같습니다(성공한 상태 함수 참조).

jobs:
- job: Foo

  steps:
  - script: echo Hello!
    condition: always() # this step will always run, even if the pipeline is canceled

- job: Bar
  dependsOn: Foo
  condition: failed() # this job will only run if Foo fails

조건에서 변수를 사용할 수도 있습니다.

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)

스테이지, 작업 또는 단계를 시작할지 여부를 결정하기 위해 조건이 평가됩니다. 즉, 런타임 시 해당 작업 단위 내에서 계산된 것은 사용할 수 없습니다. 예를 들어 구문을 사용하여 런타임 식을 $[ ] 사용하여 변수를 설정하는 작업이 있는 경우 사용자 지정 조건에서 해당 변수를 사용할 수 없습니다.

YAML은 TFS에서 지원되지 않습니다.

참고 항목

스테이지/작업/단계에 고유한 속성을 지정 condition 하는 경우 기본값 condition: succeeded()을 덮어쓰게 됩니다. 이렇게 하면 빌드가 취소된 경우에도 스테이지/작업/단계 실행이 발생할 수 있습니다. 사용자 고유의 조건을 작성할 때 부모 단계/작업의 상태를 고려해야 합니다.

사용자 지정 조건 사용

기본 제공 조건이 요구 사항을 충족하지 않는 경우 사용자 지정 조건을 지정할 수 있습니다.

조건은 YAML 파이프라인에서 식으로 작성됩니다. 에이전트는 가장 안쪽에 있는 함수로 시작하는 식을 평가하고 작동합니다. 최종 결과는 태스크, 작업 또는 단계를 실행해야 하는지 여부를 결정하는 부울 값입니다. 구문에 대한 전체 가이드는 식 문서를 참조하세요.

사용자가 빌드를 취소한 후에도 작업을 실행할 수 있는 조건이 있나요? 그렇다면 사용자가 실행을 취소한 후 이러한 종류의 작업을 완료하기에 충분한 시간을 갖도록 취소 시간 제한에 적절한 값을 지정합니다.

빌드가 취소될 때의 파이프라인 동작

빌드가 취소된 경우 모든 단계, 작업 또는 단계의 실행이 중지되는 것은 아닙니다. 결정은 지정한 단계, 작업 또는 단계 conditions 와 빌드를 취소한 파이프라인 실행 시점에 따라 달라집니다.

조건이 스테이지/작업/단계의 부모 상태를 고려하지 않는 경우 조건이 평가true되면 부모가 취소되더라도 스테이지, 작업 또는 단계가 실행됩니다. 부모를 건너뛰면 스테이지, 작업 또는 단계가 실행되지 않습니다.

몇 가지 예를 살펴보겠습니다.

이 파이프라인에서는 기본적으로 stage2 집합에 stage1stage2condition 따라 달라집니다. stage2 는 원본 분기 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

분기에서 빌드를 큐에 main 대기하고 실행 중인 stage2 동안 stage1 취소하는 경우 < a0/>로 평가되므로 true계속 실행됩니다eq(variables['Build.SourceBranch'], 'refs/heads/main').

이 파이프라인에서 . stage2stage1 작업에 B 대한 집합이 condition 있습니다.

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

분기에서 빌드를 큐에 main 대기하고 실행 중인 stage2동안 stage1 취소하는 경우 조건이 계산true되는 작업이 B 포함되어 있더라도 실행되지 않습니다. 그 이유는 취소될 때 stage1 계산되는 기본값condition: succeeded()false 있기 stage2 때문입니다. 따라서 stage2 건너뛰고 해당 작업이 실행되지 않습니다.

다음 YAML 파이프라인이 있다고 가정해 보겠습니다. 기본적으로 stage2 는 해당 집합에 따라 stage1 달라지며 script: echo 2 해당 집합이 condition 있습니다.

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')

분기에서 빌드를 큐에 main 대기하고 실행 중인 stage2동안 stage1 취소하는 경우 조건이 계산true되는 작업의 B 단계가 포함되어 있더라도 실행되지 않습니다. 그 이유는 취소에 대한 응답으로 건너뛰기 stage1 때문 stage2 입니다.

빌드가 취소될 때 단계, 작업 또는 단계 conditions 가 실행되지 않도록 하려면 작성 conditions할 때 부모의 상태를 고려해야 합니다. 자세한 내용은 작업 상태 함수를 참조하세요.

예제

실패한 경우에도 취소된 경우에도 기본 분기에 대해 실행합니다.

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')

Release.Artifacts. {artifact-alias}. SourceBranch는 Build.SourceBranch동일합니다.

변수가 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 .

condition 파이프라인의 두 함수는 다음과 같은 두 가지 함수를 결합합니다 succeeded()eq('${{ parameters.doThing }}', true). succeeded() 이전 단계가 성공하면 함수가 검사. 이 함수는 succeeded() 이전 단계가 없으므로 true를 반환합니다.

이 함수는 eq('${{ parameters.doThing }}', true) doThing 매개 변수true가 같은지 여부를 검사. doThing의 기본값은 true이므로 파이프라인에서 다른 값이 설정되지 않는 한 조건은 기본적으로 true를 반환합니다.

더 많은 템플릿 매개 변수 예제는 템플릿 형식 및 사용을 참조하세요.

parameters:
- name: doThing
  default: true
  type: boolean

steps:
- script: echo I did a thing
  condition: ${{ eq(parameters.doThing, true) }}

템플릿에 매개 변수를 전달하는 경우 템플릿에서 매개 변수 값을 설정하거나 templateContext를 사용하여 속성을 템플릿에 전달해야 합니다.

# 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) }}
# azure-pipeline.yml
parameters:
- name: doThing
  default: true 
  type: boolean

trigger:
- none

extends:
  template: parameters.yml

이 파이프라인의 출력은 I did a thing 매개 변수 doThing 가 true이기 때문입니다.

다음 작업의 조건에서 작업의 출력 변수 사용

변수를 향후 작업에 사용할 수 있도록 하고 조건에 지정할 수 있습니다. 이후 작업에 사용할 수 있는 변수는 .를 사용하여 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."

다음 단계의 조건에서 단계에서 만들어진 파이프라인 변수 사용

이후 단계에서 변수를 사용할 수 있도록 하고 조건에서 지정할 수 있습니다. 기본적으로 단계에서 만든 변수는 이후 단계에서 사용할 수 있으며 , 를 사용하여 isOutput=true다중 작업 출력 변수표시할 필요가 없습니다.

위의 접근 방식 및 범위 지정과 관련하여 유의해야 할 몇 가지 중요한 사항이 있습니다.

  • 작업의 단계에서 만든 변수는 동일한 작업의 단계로 범위가 지정됩니다.
  • 한 단계에서 만든 변수는 이후 단계에서만 환경 변수로 사용할 수 있습니다.
  • 단계에서 만든 변수는 이를 정의하는 단계에서 사용할 수 없습니다.

다음은 단계에서 파이프라인 변수를 만들고 후속 단계의 조건 및 스크립트에서 변수를 사용하는 예제입니다.

steps:

# This step creates a new pipeline variable: doThing. This variable will be available to subsquent steps.
- bash: |
    echo "##vso[task.setvariable variable=doThing]Yes"
  displayName: Step 1

# This step is able to use doThing, so it uses it in its condition
- script: |
    # You can 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 파일에서 조건은 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

빌드를 취소했지만 여전히 실행 중입니다. 무슨 일일까요?

단계에서 구성된 조건에 작업 상태 검사 함수가 포함되지 않은 경우 이 문제가 발생합니다. 이 문제를 해결하려면 작업에 상태 검사 함수를 조건에 추가합니다. 큐에 있지만 실행되지 않는 동안 작업을 취소하면 다른 모든 단계를 포함하여 전체 작업이 취소됩니다.

빌드가 취소될 때 파이프라인의 동작에 대해 자세히 알아봅니다.