CODEWITHSUNDEEP
azure-devopsazure-pipelinesazure-pipelines-yaml
Kreg
Kreg

Reputation: 43

Dependant pipeline can't continue deployment

I have a pipeline (MainPipeline) which triggers another one (DependantPipeline).

I want to have some basic task done in main pipeline (Build and Test stage) which are common for any triggered pipeline. So far triggering works as expected which means that MainPipeline triggers the DependantPipeline, however the DependantPipeline skips all stages based on my last changes (Build and Test stage and DEV stage). It should skip only Build and Test stage and let continue DEV stage.

My goal is to skip only Build and Test stage and run Dev stage at DependantPipeline. On the other hand, Build stage must work only (and pass) on MainPipeline (which in fact does). The issue is later, on DependantPipeline and the condition as I believe.

/templates/pipeline.yml@Pipelines

stages:
  - stage: Build
    displayName: Build
    condition: and(succeeded(), not(${{parameters.skipBuildAndTest}}))

/templates/deployment.yml@Pipelines

stages:
  - ${{ if ne(parameters.devEnvironment, '') }}:
    - stage: DEV
      displayName: DEV Environment
      # dependsOn: Build
      condition: succeeded()

With many attempts I am not able to achieve the desired effect.

I download log from Azure DevOps, so maybe it will be helpful. Logs says at Build stage:

stages:
- stage: Build
  displayName: Build
  condition: and(succeeded(), not(true))

Also at DEV stage it says:

- stage: DEV
  displayName: DEV Environment
  condition: succeeded()

Upvotes: 1

Views: 102

Answers (2)

Alvin Zhao - MSFT
Alvin Zhao - MSFT

Reputation: 5797

Based on the current definitions of /templates/pipeline.yml@Pipelines and /templates/pipeline.yml@Pipelines, the Deploy_DEV stage with the condition: succeeded() will run, only if the previous stage is Succeeded or SucceededWithIssues.

According to the documents below, here are some default behaviors to be taken into consideration when drafting a YAML pipeline.

When you define multiple stages in a pipeline, by default, they run sequentially in the order in which you define them in the YAML file. The exception to this is when you add dependencies. With dependencies, stages run in the order of the dependsOn requirements.

By default, stages, jobs, and steps run if all direct and indirect dependencies succeed. This status is the same as specifying condition: succeeded(). For more information, see succeeded status function

Therefore, even through you have commented out # dependsOn: Build for Deploy_DEV stage, it is still dependent on the Build stage; and once Build stage was skipped, the evaluation of Deploy_DEV stage condition would be false; thus the Deploy_DEV was skipped as well.

If you would run the two stages in sequence no matter what the status of the Build stage is, you can use the condition: always() or the condition with your specific requirement like condition: not(failed()).

Image

Or, you may set dependsOn: [] for the Deploy_DEV stage to override the default stage dependencies.

Image

Upvotes: 1

bryanbcook
bryanbcook

Reputation: 17953

Yes, your issue is being caused by your conditions.

The Build stage is being skipped because you've set the skipBuildAndTest: true, which negates the defined condition and( true, not(true) ).

The Deploy_DEV stage is being skipped because you've specified that the previous stage must be successful: condition: succeeded(). This is actually the default value.

Note that in a multi-stage pipeline with no dependencies between stages, it is assumed that the stages are sequential and therefore dependent on each other. Because the Build stage was skipped, the Deploy_DEV stage is skipped as well.

If you want to evaluate the outcome of the previous stage, you need to explicitly define the relationship so you can programmatically use it.

- stage: Deploy_DEV
  dependsOn:
  - Build
  condition: in( dependencies.Build.result, 'Succeeded', 'Skipped', '')
  ...

In the above, we're checking whether it was either Succeeded or Skipped. The condition to check for '' is to handle the edge-case when the pipeline is manually queued and the stage is deselected.

Upvotes: 0

Related Questions