azure-pipelines-tasks: Variable replacement not working in 'jobs' the same as 'deployment' jobs.
Required Information
Entering this information will route you directly to the right team and expedite traction.
Question, Bug, or Feature?
Type: bug
Enter Task Name: Docker@2
list here (V# not needed):
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks
Environment
-
Server - Azure Pipelines or TFS on-premises? Azure Pipelines
-
Agent - Hosted or Private: Microsoft Hosted Agent
Issue Description
I have a simple task like this:
- task: Docker@2
displayName: Login to Docker Hub
inputs:
command: login
containerRegistry: '$(dockerRegistry)'
If I define variable dockerRegistry
within the pipeline file (inside variables
block) then it works fine.
However, if I import it from Pipeline Library like this:
variables:
- group: 'Release'
then it does not work, the error message was "There was a resource authorization issue: “The pipeline is not valid. Job Build_and_Publish: Step Docker1 input containerRegistry references service connection $(dockerRegistry) which could not be found. The service connection does not exist or has not been authorized for use. For authorization details, refer to https://aka.ms/yamlauthz.”
I tried some simple echo and confirmed that echo $(containerRegistry)
(and other variables in the same libary) works (i.e. the printed value is correct).
Task logs
[Enable debug logging and please provide the zip file containing all the logs for a speedy resolution]
Troubleshooting
Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting
Error logs
[Insert error from the logs here for a quick overview]
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 6
- Comments: 35 (6 by maintainers)
We had the same issue. And we solved using the workaround moving the variable group to the top level with a conditional as suggested by @Zachery2008
I found a solution. You can save the acr connection as a variable in a variable group. And if you want to choose different variable groups depending on some conditions, you can do it at the top level. So the
containerRegistry
will treat it correctly. For example,Has there been any update on this or a workaround @richatcosta?
having exactly the same setup as @richatcosta. Also looking for advice on how do deal with it.
I figured out a way how to use different variable groups for different stages, even if the variable groups share the same variable names (with different values). I still don’t understand why Microsoft hasn’t fixed this…
main.yaml:
deploy-environment.yaml:
Somehow different variable groups only work with attribute “- deployment” within jobs. Don’t ask me why. As a workaround I used “- deployment” also for my build steps.
Microsoft should offer different variable groups for different stages…
Hopefully this helps somebody.
@channeladam I am not working on Azure DevOps anymore. I will let other team members help you with this issue if it is still continuing.
Thank you @spasal . That helped
If I remember correctly it worked for me when using the syntax
${{ variables['NameOfVariable.WithDotNotation'] }}
Please see Runtime expression syntax,
$(var)
is processed runtime before a task executes, but the service connection is checked before that.Sometimes moving the variable group top level is not ideal, as the connection might be different per stage.
Good luck!
This still appears to be an issue - and as per the comment from @sonnehansen it is an issue when wanting to use a (dynamically-selected) variable group in a template (or variable template etc):
release-pipeline.yml
file:build-template.yml
file:Attempting to refer to a variable in the variable group as part of the steps results in the errors posted earlier eg “references $(foo) which was not found”
@ds-ms @zachariahcox it would be good to get an update from Microsoft on this - if any fix is planned etc. Or if not, what the recommended workaround is, and official documentation around this if possible.
Thank you all for the investigation 😃
An identical issue occurs for variables from a template in a
jobs
section (and works fordeployment
type):jobs
the variables$(ACR)
and$(ACRSubscriptionEndpoint)
does not resolve (butimageName
does):template: variables.yml@repo
to the top level it works, as reported by @btnguyen2k.@ds-ms: It has been a while since there was any activity here. Can you confirm if MS will fix the issue because it is a bug, or we must settle for the (top level) work-around?