boolean variable as template parameter input

Question

I am trying to use variables set with the Variables-Screen in Azure Pipelines as the input for a template parameter, but get the error:

Encountered error(s) while parsing pipeline YAML: /azure-pipelines.yml (Line: 18, Col: 25): The 'androidIsLibrary' parameter value '$(ANDROID_IS_LIBRARY)' is not a valid Boolean.

I built a template within Azure Pipelines. The template takes several Parameters. On of it looks like this:

parameters:
  - name: androidIsLibrary
    type: boolean
    default: false

I have set a variable inside a variable group ANDROID_IS_LIBRARY with value false.

I added the variable group inside my pipeline with the following statement:

variables:
  - group: adr-general-library

After that I included my template with parameter as shown here:

jobs:
  - template: job--android--build_and_deploy.yml@templates
    parameters:
      androidIsLibrary: $(ANDROID_IS_LIBRARY)

I can't find an example for this particular use case in the Azure DevOps documentation, so I hope somebody already faced that problem. I want to use that template with parameters but want to structure my parameters centralized in a variable group. There are a lot more variables and parameters, so it is not a solution to just put the variable definition directly into the templates. And I am also not able to change the template.

Thanks in advance

Answer 1

I have encountered the exact same issue before.

The root cause of this issue is that the variable in variable group is string type instead of the boolean type.

So when you pass the variable value to parameter, it will show the error message.

I confirmed this issue with our product group and this is by design.

This is the reply:

at the point where we're processing ${{ templates }}, the contents of $(variables) are not processed. So indeed, "$(BooleanVar)" will never be a boolean. In fact, no variable can ever be a boolean - variables are always strings. This is working as designed.

For a workaround, you need to change the parameter type as string type in Template:

For example:

parameters:
  - name: androidIsLibrary
    type: string
    default: false

Then it will work.

Another method is that you could define the variable in the Main Yaml file and use this format ${{variables.variablename}}

For example:

variables:
  - name: one
    value: true

steps:
  - template: build.yml
    parameters:
      androidIsLibrary: ${{ variables.one }} 

Answer 2

Not ideal but this should work:

jobs:
  - template: job--android--build_and_deploy.yml@templates
    parameters:
      ${{ if eq(variables['ANDROID_IS_LIBRARY'], 'true') }}:
        androidIsLibrary: true
      differentParam: 'someText'

Answer 3

This happens because template expansion is done before variable expansion (docs). Variable references like $(Foo) are not yet processed when the template parameter type is validated.

The first step in pipeline processing is only about replacing all template: xxx references in the YAML tree with the target YAML elements, and handling template parameters and any encountered template (compile-time) expressions, which look like ${{ ... }}.

---

The error message which goes like
      “The 'someVar' parameter value '$(SOME_VAR)' is not a valid Boolean.”
does not mean that the content of the variable SOME_VAR is wrong (not true or false).

It means that the literal text $(SOME_VAR), i.e. including the dollar sign, the parentheses and the variable name, is not a valid boolean value. Because that's all the parser sees at the time it is doing this early template expansion.

If the type of the template parameter was changed to a string, it would naturally accept even the value of $(SOME_VAR). But an expression like ${{ parameters.someVar }} encountered later inside the template would not be replaced with a True or False, as one might expect.

It would rather be replaced again just with the literal text $(SOME_VAR), as it is. And only later, when actually running the relevant step or doing other evaluation, it might get replaced with the real value the variable has at the moment (that is, if these variable expansions are allowed in the given context at all).

(On the other hand, it is superfluous to reference boolean template parameters in constructs formatted like e.g. condition: eq(${{ parameters.someVar }}, 'true'). The inner expression will already only ever expand to the real true or false value, so just condition: ${{ parameters.someVar }} is enough.)

---

The docs specify that only "parameters and statically defined variables" can be accessed from the compile-time template expressions in format ${{ ... }} . This means that even if there is a syntax which allows referencing variables like variables.Foo or variables['Foo'], it does not work for all of them at this time.

The list of predefined variables has a dedicated column "Available in templates?", which shows whether it is possible to use each of them during the early template expressions evaluation or not.

What "statically defined" means with user-defined variables, the variable must be set in the variables section of the YAML file. Providing it only in the pipeline definition or only when starting the build in the ADO UI would not work (it would expand to an empty string). But variables set statically in the YAML file cannot be set (overridden) from the UI at all, which is quite limiting...

---

My suggestion is to use parameters instead of variables

at least for values that are supposed to be changed by users sometimes.

They are much better than variables for this purpose, allowing one to prepare a nice UI with properly labeled text boxes, checkboxes, radio buttons etc., instead of the poor string-only variables experience:

And well, most importantly, they work when passed as parameters further to templates.

But yes, they are not a replacement for things like variable groups. Changing the inner template might be needed then, to reference relevant variables directly, or take string parameters instead of typed boolean etc. after all.

Answer 4

When you pass parameter to template you need to use ${{ parameters.xyz }} syntax