Azure YAML-Pipeline skips jobs and I have no idea why

Question

Even though I set System.Debug=True I get no other information than "The job was skipped". Literally just these four words.

I created a YAML-Release pipeline on Azure Devops which basically runs the jobs:

• job: build_release
• jobs: deployment: deploy_test
• jobs: deployment: deploy_stage

To test the behavior I first only ran the first two jobs and deployed to TEST. Now I want to deploy to STAGE but it seems that the pipeline is only working when I start from the beginning / create a new release. But what I want to do right now is to deploy the already existing release from TEST to STAGE. When I try to do that by rerunning the pipeline Azure just skips all steps. Why is this happening? How can I avoid this and rerun the pipeline? I did not set any conditions.

EDIT with additonal info:

Structure of the pipeline

---

trigger:
    - release/*

variables:
     ...

resources:
    -   repo: self


pool:
    vmImage: $(vmImageName)

stages:
    -   stage: build_release
        displayName: 'awesome build'
        condition: contains(variables['Build.SourceBranchName'], 'release/')
        jobs:
            -   job: build_release
                steps:
                    ...

    -   stage: deploy_test
        displayName: 'awesome test deploy'
        jobs:
            -   deployment: deploy_test
                environment: 'test'
                strategy:
                    runOnce:
                        deploy:
                            steps:
                               ...

    -   stage: deploy_stage
        displayName: 'awesome stage deploy'
        jobs:
            -   deployment: deploy_stage
                environment: 'stage'
                strategy:
                    runOnce:
                        deploy:
                            steps:
                               ...

---

I tried to trigger it in two different ways which had the same outcome (everything was skipped): A. I created a new release which was a copy of the previously deployed release. B. I clicked on run pipeline.

Stuck

Normally you have a single build pipeline then a release pipeline that deploys to multiple stage so you get to build once and deploy many. – Chatelain

Look at stages, environments and dependencies, example here: github.com/microsoft/azure-devops-extension-tasks/blob/main/… – Noenoel

@BassamGamal I could try splitting these pipelines up but unsure if it would help and I still don't understand why all jobs are skipped. – Stuck

@Noenoel I looked at it but still can't figure out why all jobs in my pipeline are skipped when I rerun the pipeline or trigger it with an identical release. – Stuck

We don't have enough data to tell you :). Are there any conditions on the jobs? Can you share a few more details of your pipeline? And what state it was in before you re-ran it? How you trigger it, there is a lot to unpack in your post for which I'm not entirely sure what you are doing. It doesn't seem to be the way it's intended ;). – Noenoel

@Noenoel I made an edit and hope that it answers all your questions. Not sure what you mean by "state it was in" since I triggered a new pipeline. There are no conditions for the deployments. – Stuck

Make sure you add the dependsOn: 'build_release' to the stages to make them depend on eachothers so they can pick up eachother's artifacts. I still can't explain the behavior you're seeing based on what you've shared. Any chance you can share the diagnostics logs? Even privately? – Noenoel

These comments are misleading. @BassamGamal here is referring to YAML pipelines not classic Releases. – Regularly

Answer 1

The issue is caused by the condition condition: contains(variables['Build.SourceBranchName'], 'release/'), which you specified for stage build_release.

When the trigger is set to - release/*. The variable variables['Build.SourceBranchName'] will be evaluated to the branch name after the /.

For example:

If you triggered your pipeline from branch release/release1.0. the value of variables['Build.SourceBranchName'] will be release1.0 instead of release/release1.0. So the condition contains(variables['Build.SourceBranchName'], 'release/') will always be false, which caused the stage build_release to be skipped.

And, if you didnot specify dependency for stage deploy_test and stage deploy_stage, the next stage will depends on the previous stage by default. So these two stages also got skipped, since stage build_release is skipped. This is why you saw all the steps were skipped.

Solution:

Using variable Build.SourceBranch in the condition.

Change the condition like below: (The yaml file in the release branches should also be changed like below)

- stage: build_release
  displayName: 'awesome build'
  condition: contains(variables['Build.SourceBranch'], 'release/') #use Build.SourceBranch

Noted: If you mannaly triggered your pipeline. Please make sure your select to trigger the pipeline from release branches. Or the pipeline will be triggered from main branch by default.

Householder

Thank you and @Noenoel for your comments. Apparently there were two issues with the pipeline. 1. As this answer explains, the condition was wrongly set which makes total sense. 2. As jessehouwing explained I needed to use "dependsOn" for every stage. This does not make sense to me yet since stages run sequentially anyways? But it does work fine. – Stuck

The other pipelines run in sequence ony when there is only one agent available to service them. In my case I have 12 active agents, so in that case all 3 stages will trigger in parallel. The dependencies enforce sequential execution. – Noenoel

Answer 2

The issue here is when the run of the pipeline was create it sounds like the deploy stage was not selected. As such at compilation time of the pipeline the stage was skipped as it was defined as being skipped within that run.

As for what you are running the first question would be are these changes to run the deploy_stage is this in the main branch? The pipeline by default will run against the main branch unless otherwise specified.

Regularly