TriggerBuild yaml pipeline - Passing parameter doesnt override default value

[GitHubAre]

Hello,

We use latest version 3.1.1 of the extension. task TriggerBuild@3

I have a pipeline in YAML that triggers another one, this is in the calling pipeline

  - task: TriggerBuild@3
    displayName: 'Trigger SIPTEST pipeline'
    inputs:
      buildDefinition: 'siptest'
      useSameBranch: false
      branchToUse: master
      waitForQueuedBuildsToFinish: true
      authenticationMethod: 'OAuth Token'
      password: $(System.AccessToken)
      queueBuildForUserThatTriggeredBuild: true
      waitForQueuedBuildsToFinishRefreshTime: 15
      buildParameters: >
        mcugitsha: $(Build.SourceVersion),
        TriggeredBy: Triggered_by_$(Build.DefinitionName)/$(Build.BuildNumber)

another is also yaml pipeline, this one is triggered from above task: parameters:

- name: mcugitsha
  type: string
  default: testwest

steps:
  - powershell: |
      Get-ChildItem -Path Env: | %{write-host "$($_.Name) = $($_.Value)"}
  - script: echo ${{parameters.mcugitsha}}

The "script" step prints always: echo testwest Which is the default value. Based on what I can see in this issue: https://github.com/huserben/TfsExtensions/issues/153 It should be possible to pass the parameter inside. I can access the $(mcugitsha) variable, but its not the "prettiest" because its not explicitly declared. I havent found real good example of this yaml syntax, therefore I might have used it incorrectly.

[huserben]

Hi @GitHubAre

I quickly recreated your scenario and for me it works. I have a pipeline that defines two template parameters, one with free text and one with a defined set of accepted values:

parameters:
- name: image
  displayName: Pool Image
  type: string
  default: ubuntu-latest
  values:
  - windows-latest
  - vs2017-win2016
  - ubuntu-latest
  - ubuntu-16.04
  - macOS-latest
  - macOS-10.14
- name: Test
  type: string
  default: Whatever

trigger: none

jobs:
- job: build
  displayName: build
  pool: 
    vmImage: ${{ parameters.image }}
  steps:
  - script: echo building $(Build.BuildNumber) with ${{ parameters.image }}

  - script: echo Test is ${{ parameters.Test }}

Then I triggered this with this command from another pipeline:

- task: TriggerBuild@3
  inputs:
    definitionIsInCurrentTeamProject: true
    buildDefinition: 'SomeGitRepo'
    queueBuildForUserThatTriggeredBuild: true
    ignoreSslCertificateErrors: false
    useSameSourceVersion: false
    useCustomSourceVersion: false
    useSameBranch: true
    waitForQueuedBuildsToFinish: false
    storeInEnvironmentVariable: false
    templateParameters: 'image: windows-latest, Test: TriggeredByBuild'
    authenticationMethod: 'OAuth Token'
    password: '$(System.AccessToken)'
    enableBuildInQueueCondition: false
    dependentOnSuccessfulBuildCondition: false
    dependentOnFailedBuildCondition: false
    checkbuildsoncurrentbranch: false
    failTaskIfConditionsAreNotFulfilled: false

This results in the build being triggered and correctly showing "TriggeredByBuild":

Where does this leave us? My first hunch was - did you correctly specify the parameters as template parameters and not as "regular" variable? Do you spot anything that is different from my code above to yours that could make it not work for you? Did we exclude the obvious things, like some typo or so in the variable name?

[GitHubAre]

I have simplified my test even more and now I am just using the templateParameters:

steps:
  - task: TriggerBuild@3
    displayName: 'Trigger SIPTEST pipeline'
    inputs:
      buildDefinition: 'siptest'
      useSameBranch: false
      branchToUse: master
      waitForQueuedBuildsToFinish: true
      authenticationMethod: 'OAuth Token'
      password: $(System.AccessToken)
      queueBuildForUserThatTriggeredBuild: true
      waitForQueuedBuildsToFinishRefreshTime: 15
      templateParameters: 'mcugitsha: $(Build.SourceVersion)'

Output from the calling pipeline:

Context is Build - using Build Environment Variables
Build shall be triggered for same user that triggered current build: userxyz
Will trigger build with following template parameters: mcugitsha: 409dfdbe92f0d15e0ed77b4494af9590a0c4cc10
Found parameter mcugitsha with value: 409dfdbe92f0d15e0ed77b4494af9590a0c4cc10
Queued new Build for definition siptest: https://tfsurl.net/tfs/Playground/c87e4c70-d159-44bd-a79a-5643e7ea1adb/_build/results?buildId=1068
Will wait for queued build to be finished - Refresh time is set to 15 seconds
Following Builds will be awaited:
Build 1068 (siptest): https://tfsurl.net/tfs/Playground/c87e4c70-d159-44bd-a79a-5643e7ea1adb/_build/results?buildId=1068
Waiting for builds to finish - This might take a while...

But this still prints the default value:

parameters:
  - name: mcugitsha
    type: string
    default: testwest

trigger: none

steps:
  - powershell: |
      Get-ChildItem -Path Env: | %{write-host "$($_.Name) = $($_.Value)"}
  - script: echo ${{parameters.mcugitsha}}

We have on-premise server installation, maybe it doesnt work there and only in azure devops cloud. I cant see any other explanation :(

[huserben]

Yeah so syntax wise this all looks good. It could be that there is a difference from Azure DevOps cloud to on-prem version, as the API to specifiy the parameters was implemented a bit later than the actual template pareameters themselves, so it might not have made the cut...could you try once to not set any default value and see what happens?

Do you need to use template parameters? As with "regular variables" it should work, but of course there are some downsides to that...

Also I see you use pass the source version, if it's only about that I would also propose to use the dedicated source version parameter, then the triggered build will use this specific version of the source (this works when you are using git).

[GitHubAre]

I have tried a lot of combinations already, without default value it fails when used normally (without the TriggerBuild).

The thing with passing git sha (Build.SourceVersion) is more complex, I will write a script that will update git submodule to that specific sha, and there will be multiple submodules for each there can be different sha as parameter, therefore this simple example was just to see what I can do with the TriggerBuild task.

I will be able to use it without the parameters (using implicit variables that are working fine).

I will close this issue.

[GitHubAre]

Forgot to thank you for this great feature and providing very quick help with clarifying my questions, many thanks!

[huserben]

Ok, I'm sorry we couldn't make it work.

However in case you update your on-prem instance in future and decide to give it a try again, let me know. I'm curious now whether this is the reason.

Thanks for using the task and raising this issue. While we didn't manage to solve it, it might help others with the same or similar problems.

If in future you have any questions, problems or ideas regarding the task(s), feel free to create another issue.

[francisco-maciel]

Hello @huserben I was also stuck on this issue, even using the latest v4.

In our case, it is also an issue for an on-premise server installation, Version Dev18.M170.6. Once we update I can give feedback if this is no longer an issue on a more recent version.

[ravi46kom]

Hi @huserben i want to use BuildParameter instead of tem..parameter but, getting validation error while triggering pipeline.

[huserben]

@ravi46kom Where/how did you specify the "platform" parameter on the build to be triggered?

Did you make sure that you can override it?

[ravi46kom]

Hello @huserben Thanks a lot for quick response , I'm new on azure and learning. I forgot to override on run time. But how can we override while running pipeline if we're using secret variable?

[huserben]

Don't worry about it. Did this solve your problem then?

[ravi46kom]

it's solve for demo codes but in project I'm using secret variable and there is no option to set

[huserben]

Are you talking about variables from a variable group? If so, this is not supported by the task (or Azure Pipelines for that matter). Variable group variables are not overridable, so the only way to adjust it would be to:

1. Change the variable value
2. Trigger the Pipeline
3. Optionally: Change back the variable value to the default value

This would require some manual scripting from you to set the variable value before triggering the pipeline.

[ravi46kom]

Hi @huserben First of all many thanks to explain Overriding, it's working fine in projects also.

[sathishreddy48]

Is this issue closed ? we are still unable to send the parameters from YAML to build pipeline , build pipeline is running with default parameters always .

[huserben]

Hi @sathishreddy48

yes, this issue was closed some time ago as it was probably related to the on-prem version.

I suggest that you open a new issue and share as much detail as you can about your context:

• Are you using Azure DevOps or Azure DevOps Server?
• How is the task configured?
• How does the triggered pipeline look like

Otherwise, it will be difficult to help, as the general scenario seems to be working in all my tests. Using a dedicated issue will be best to keep the focus on your problem.