0

I've got two (YAML) pipelines in Azure DevOps, call them B (application build) and D (application deployment). D deploys to Dev, QA, and Test, each in a separate stage. The QA and Test environments are configured in DevOps to require approval before their respective stages in D are executed. The YAML files behind B and D are in the same DevOps project.

The code repository is Azure DevOps Git. B is triggered by completed merges to the main branch. D is triggered by successful completion of B. In case it matters, the means by which I've configured D to be triggered by successful completion of B is via

the Triggers option on this menu for the pipeline with Settings, Validate, and Donwload full YAML as other available commands

leading to

the Triggers config tab for the YAML pipeline, between the Variables and History tabs

So far, this arrangement has worked well.

Now I want B to be triggered by not only feature pushes to main but by hotfix pushes to any branch named release/*. So,

  trigger:
    - main
    - release/*

The difference is that the hotfixes should be deployed only to Test, not to Dev or QA.

Therefore, in D, I want to make execution of the Dev and QA deployment stages conditional on the triggering branch of B having been main. Is there some way in D to access from B the value that in B can be referenced as $(Build.SourceBranch)?

UPDATE: I now learn that the manner I described above for having D triggered by B is itself outmoded, and I should be using something like

resources:
  pipelines:
    - pipeline: sourcePipeline
      source: 'B'
      trigger:
        branches:
          - main
          - release/*

Is that the correct way to set this up? Do I need to specify the branches here or are they relevant? (I saw one example that simply has trigger: true, which I'm guessing means that the second pipeline should always be run after the first completes. Perhaps branches are specified above only when B may be triggered by lots of branches but D should run after B only when B was triggered by a subset of those.)

If this is the preferred approach and I switch to it, does the answer to my question become that I can now access B's triggering branch in D through $(resources.pipeline.sourcePipeline.SourceBranch)?

1 Answer 1

0

In the absence of a response I continued with my project and engaged in some painful experimentation. In the end, my guesses turned out to be correct:

  • Replace the Classic method of triggering D off of B with the YAML method, like this:
  resources:
    pipelines:
      - pipeline: sourcePipeline
        source: 'B'
        trigger: true

And this requires replacing Build variables like Build.SourceBranch with pipeline variables: resources.pipeline.sourcePipeline.SourceBranch is correct.

Finally (bonus answer to a question I hadn't asked here), it turns out you can't use condition: on stages that are template invocations. So instead I had to create a canRun parameter for the template being invoked, setting it to the same expression I would have used in a condition:, and then referencing canRun in condition:s in the template.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.