Down the rabbit hole – Undeclared pipeline variables

A small blog post on something I learned today and could not find that easy on the internet. Apparently you can use parts of the service-connection added an AzureCli Task as variables in your script. For your time sakes, this is the summary and not the entire process that took way to long 🙂


Today I noticed a small thing in a YAML script, so down the rabbit hole, I went.

        - task: AzureCLI@1
          displayName: 'Executing Script'
            azureSubscription: ${{ parameters.armServiceConnection }}
            scriptLocation: inlineScript
            inlineScript: |
              echo "about to run docker"
              docker login -u $servicePrincipalId -p $servicePrincipalKey ${{ parameters.Registry }}

Strange thing is that I know where the parameters.armServiceConnection comes from, but the $servicePrincipalId and $servicePrincipalKey are not defined. Neither passed as a parameter and not as a pipeline variable, so where does it come from?


When I enabled diagnostic logging (system.debug=true) I noticed the following

##[debug]loading ENDPOINT_AUTH_XXX

This looks like what I am looking for. Let’s try something, create a new YAML file from the default pipeline template and add the AzureCli Task and try and print the variables.

- task: AzureCLI@2
    azureSubscription: 'MySubscription'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |

      echo "about to run docker"
      echo "$servicePrincipalId" 
      echo "$servicePrincipalKey"

      echo "bam $myspecialikke endbam"
    addSpnToEnvironment: true

The result from running is as I expected, the $servicePrincipalId is being filled by the Task and are replaced by ***, while my not declared variable $myspecialikke is just left blank.

/bin/bash /home/vsts/work/_temp/
about to run docker
bam  endbam


Of course, we don’t read any instruction manual, because that would be too easy. Diving directly into troubleshooting modus and analyzing how things work is our prime response.

When writing this blog I wanted to reference the task in GitHub and noticed the .md file.

Still think this is a cool way to re-use your service connection instead of passing 3 more variables into your pipeline. Though it was a little obscure when I noticed the YAML the first time.

Sometimes just being familiar with the Tasks and RTFM can save a lot of time and a simple line of comments could have saved me a lot of time.


You may also like...

Leave a Reply