조건 지정

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

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

참고

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

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

  • 동일한 에이전트 풀을 가진 이전의 모든 직접 및 간접 종속성이 성공한 경우에만 가능합니다. 다른 에이전트 풀이 있는 경우 해당 단계 또는 작업이 동시에 실행됩니다. 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 에 따라 stage1 달라지고 stage2 집합이 있습니다 condition . stage2main원본 분기가 인 경우에만 실행됩니다.

stages:
- stage: stage1
  jobs:
  - job: A
    steps:
      - script: echo 1; sleep 30
- stage: stage2
  condition: contains(variables['build.sourceBranch'], 'refs/heads/main')
  jobs:
  - job: B
    steps:
      - script: echo 2

분기에서 빌드를 큐에 main 대기하고 실행 중인 stage2 동안 stage1 취소하는 경우 가 로 평가true되기 때문에 contains(variables['build.sourceBranch'], 'refs/heads/main') 가 계속 실행됩니다.

이 파이프라인에서 는 stage1 에 따라 stage2달라집니다. 작업에 B 대한 집합이 condition 있습니다.

stages:
- stage: stage1
  jobs:
  - job: A
    steps:
      - script: echo 1; sleep 30
- stage: stage2
  jobs:
  - job: B
    condition: contains(variables['build.sourceBranch'], 'refs/heads/main')
    steps:
      - script: echo 2

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

다음 YAML 파이프라인이 있다고 가정해 봅시다. 기본적으로 stage1 에 따라 stage2 달라 지고 그에 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: contains(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'))

분기가 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}. SourceBranchBuild.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 실행됩니다.

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

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

그러나 매개 변수를 템플릿에 전달하면 조건이 평가될 때 매개 변수에 값이 없습니다. 결과적으로 템플릿과 파이프라인 YAML 파일 모두에서 매개 변수 값을 설정하면 템플릿의 값이 조건에 사용됩니다.

# 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: and(succeeded(), 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 파일에서 작업 A가 문제에 성공했기 때문에 조건을 eq(dependencies.A.result,'SucceededWithIssues') 사용하면 작업을 실행할 수 있습니다.

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

빌드를 취소했지만 여전히 실행 중입니다. 이유가 무엇입니까?

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

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