Pass boolean buildParameter

[ArianMoinianMicrosoft]

Hello
How can I pass boolean buildParameter to the triggered build?
Best,
Arian

[huserben]

Hi @ArianMoinianMicrosoft

what have you tried so far? Could you share a snippet of your pipeline (yaml or a screenshot if you use classic builds).

BuildParameters do not have a type if I remember correctly, so everything will be a string. Template Parameters can be typed, but in the task you still just send true/false and it should be converted automatically.

Hope that helps a bit - otherwise I'd need some more info about the specific use case.

[huserben]

@ArianMoinianMicrosoft
Any update on this? As otherwise I'll close due to inactivity.

[avang-MT]

Hi @huserben,

I am having the same exact issue where the downstream template parameters are expecting a boolean parameter type. As a result of expecting a boolean parameter value, the upstream pipeline using the buildTrigger task fails.

Below is the upstream pipeline using the buildTrigger task and failing with template parameters and it's pipeline template definition:

Below is the downstream template type parameters the downstream pipeline is expecting:

As a result, I had to convert all boolean parameter types to string. And I could not use a list of predefined values for string type parameter seen at the bottom:

Thanks in advance.

[huserben]

Hi @avang-MT

to understand correctly. You only had to change the downstream pipeline template types (from boolean to string) and then the triggering worked, without any additional changes?

If so it might be a limitation by the API. Sadly it's not really documented how to use the template parameters, so it's hard for me to tell what could be wrong.

What could help is if you could create a pipeline with a bool parameter and trigger it manually and capture the request that is sent (via the browser network tools). Perhaps we could reverse engineer if there is some specific thing sent if it's a bool value. However, if that would be the case, it would be tricky to handle this in the task, given that it's already quite messy now.

Anyway, if you could provide the request sent via manual triggering it's something to look at. Right now I'm short on time so I don't have any space to check this out in detail myself, so your support would be appreciated. Otherwise, I can try this myself, but you might have to way a bit longer.

Thanks!

[avang-MT]

Hi @avang-MT

to understand correctly. You only had to change the downstream pipeline template types (from boolean to string) and then the triggering worked, without any additional changes?

If so it might be a limitation by the API. Sadly it's not really documented how to use the template parameters, so it's hard for me to tell what could be wrong.

What could help is if you could create a pipeline with a bool parameter and trigger it manually and capture the request that is sent (via the browser network tools). Perhaps we could reverse engineer if there is some specific thing sent if it's a bool value. However, if that would be the case, it would be tricky to handle this in the task, given that it's already quite messy now.

Anyway, if you could provide the request sent via manual triggering it's something to look at. Right now I'm short on time so I don't have any space to check this out in detail myself, so your support would be appreciated. Otherwise, I can try this myself, but you might have to way a bit longer.

Thanks!

That's correct, in order for the downstream pipeline to be properly triggered I had to convert boolean types to string AND remove specified values accepted by the last parameter.

I'll manually test this in a development pipeline and let you know what I observe.

Updates to come.

Thanks.

[avang-MT]

@huserben this is what I am seeing, templateParameters appears to convert the boolean into a string:

Template:

Payloads (True & False conditions):

Is this a limitation by the API perhaps?

[huserben]

Thanks for checking this.

It could still be on "my" side and not the API. I have to dive a bit deeper into the logic and see what is going on.
I'll update you here once I have more news. However, I cannot make any predictions about when I will get to it.

So I'm afraid that for the time being you have to stay on your changed template with the strings instead of the boolean. I hope that is ok with you.

[avang-MT]

Thanks for checking this.

It could still be on "my" side and not the API. I have to dive a bit deeper into the logic and see what is going on. I'll update you here once I have more news. However, I cannot make any predictions about when I will get to it.

So I'm afraid that for the time being you have to stay on your changed template with the strings instead of the boolean. I hope that is ok with you.

Thank you. We have a temporary workaround to get us moving forward for the time-being. Keep us posted here for any updates.

Best regards

[iforapsy]

The current issue title is misworded as this discussion is about templateParameters and not buildParameters (aka queue time variables). huserben is correct that buildParameters don't seem to have a type: they are all strings.

Using Azure DevOps Server 2022.1 and TriggerBuild@4, I was able to trigger a build with a boolean template (aka runtime) parameter by passing the boolean value as all-lowercase and no quotes.

Here's the relevant excerpt from my working YAML pipeline definition. My pipeline triggers itself (i.e. it is recursive). expandWildcards is the boolean parameter.

parameters:
- name: applicationList
  displayName: Names of applications to import (comma-separated). Wildcards supported.
  type: string
  default: '*'
- name: expandWildcards
  displayName: Expand wildcards in application names?
  type: boolean
  default: true

[...]
jobs:
- job: import
  steps:
  [...]
  - task: TriggerBuild@4
    displayName: Trigger this pipeline with expanded application list
    inputs:
      definitionIsInCurrentTeamProject: true
      buildDefinition: $(System.DefinitionId)
      # Misnomer: templateParameters is for runtime parameters
      templateParameters: >
        applicationList:$(applicationList),
        expandWildcards:false
      # Misnomer: buildParameters is for queue time variables
      buildParameters: >  # Propagate System.Debug and Agent.Diagnostic variables
        system.debug:$(System.Debug),
        agent.diagnostic:$(Agent.Diagnostic)
      authenticationMethod: 'OAuth Token'
      enableBuildInQueueCondition: false
      dependentOnSuccessfulBuildCondition: false
      dependentOnFailedBuildCondition: false
      checkbuildsoncurrentbranch: false
      failTaskIfConditionsAreNotFulfilled: false
[...]

Bonus: my excerpt shows how to pass in fake-boolean buildParameters as that's what System.Debug and Agent.Diagnostic are. Hope this helps someone.