Answers: <p>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:</p>
  <ul>
  <li>Replace the Classic method of triggering D off of B with the YAML method, like this:</li>
  </ul>
  <pre><code>  resources:
      pipelines:
        - pipeline: sourcePipeline
          source: 'B'
          trigger: true
  </code></pre>
  <p>And this requires replacing Build variables like Build.SourceBranch with pipeline variables: <code>resources.pipeline.sourcePipeline.SourceBranch</code> is correct.</p>
  <p>Finally (bonus answer to a question I hadn't asked here), it turns out you can't use <code>condition:</code> on stages that are template invocations. So instead I had to create a <code>canRun</code> parameter for the template being invoked, setting it to the same expression I would have used in a <code>condition:</code>, and then referencing <code>canRun</code> in <code>condition:</code>s in the template.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-11-09T13:21:30.740Z
Answers: 2022-11-09T13:21:30.740Z
Answers: Green Grasso Holm
Body: <p>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.</p>
  <p>The code repository is Azure DevOps Git. B is triggered by completed merges to the <code>main</code> 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</p>
  <p><a href="https://i.sstatic.net/f2qva.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/f2qva.png" alt="the Triggers option on this menu for the pipeline with Settings, Validate, and Donwload full YAML as other available commands" /></a></p>
  <p>leading to</p>
  <p><a href="https://i.sstatic.net/S4pwE.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/S4pwE.png" alt="the Triggers config tab for the YAML pipeline, between the Variables and History tabs" /></a></p>
  <p>So far, this arrangement has worked well.</p>
  <p>Now I want B to be triggered by not only feature pushes to <code>main</code> but by hotfix pushes to any branch named <code>release/*</code>. So,</p>
  <pre><code>  trigger:
      - main
      - release/*
  </code></pre>
  <p>The difference is that the hotfixes should be deployed only to Test, not to Dev or QA.</p>
  <p>Therefore, in D, I want to make execution of the Dev and QA deployment stages conditional on the triggering branch of B having been <code>main</code>. Is there some way in D to access from B the value that <em>in</em> B can be referenced as <code>$(Build.SourceBranch)</code>?</p>
  <p>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</p>
  <pre><code>resources:
    pipelines:
      - pipeline: sourcePipeline
        source: 'B'
        trigger:
          branches:
            - main
            - release/*
  </code></pre>
  <p>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 <code>trigger: true</code>, which I'm guessing means that the second pipeline should <em>always</em> 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.)</p>
  <p>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  <code>$(resources.pipeline.sourcePipeline.SourceBranch)</code>?</p>
  
Tags: <azure-devops><azure-pipelines>
Title: Azure DevOps, get the triggering branch of the triggering pipeline
UserDisplayName: Green Grasso Holm
ThreadText: # Azure DevOps, get the triggering branch of the triggering pipeline
  
  (Asked by: username_0 on 2022-11-04)
  
  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](https://i.sstatic.net/f2qva.png)](https://i.sstatic.net/f2qva.png)
  
  leading to
  
  [![the Triggers config tab for the YAML pipeline, between the Variables and History tabs](https://i.sstatic.net/S4pwE.png)](https://i.sstatic.net/S4pwE.png)
  
  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)`?
  
  **Tags:** azure-devops, azure-pipelines
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2022-11-09. Score: 0 | Accepted answer
  
  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.
  
  
  ---
  
  