I would like to use "download secure file" in a dev azure task - and that works exactly as expected within a task in "release pipeline" (in "Releases"). However, when I try to do the same in a "Builds" task in azure-pipelines.yml I get "file some-uuid not found".
From the official documentation I cannot find any difference if a custom task is used in "Builds" or "Releases" - it just refers to tasks no matter where it is being used -
Is there anything I can do to access one of my secure files from the library in an azure-pipelines.yml ("Builds" task) ?
I found the answer here:
https://github.com/Microsoft/azure-pipelines-agent/issues/1809
Under SOME circumstances Azure scans the 'azure-pipeline.yml' behind the scenes and when there is e.g. a request for a resource such as 'Library/secure file' or a 'service connection' is found then the appropriate permissions are set by Azure silently - so executing the build script won't run into an error.
BUT this scan for resources will NOT happen always e.g. on commit - only if the azure-pipeline.yml is created new or a variable is added or changed.
So normal editing such as write / commit of azure-pipeline.yml will not (re-)start such a scan - and if you add tasks that requires secure file or service connection later on you will experience an error saying 'file not found' or 'insufficient permissions'.
The easiest way to enforce a rescan with permission adjustment is to go to the variable tab and e.g. change the variable system.debug = false to true - or add a new variable foo = bar .
I was not able to find any of these hints or some background in the official docs - or not in a context which was helpful to relate to this problem - and as of this writing (Nov 2018) it is not clear if this is a bug or a feature - in any case it would be helpful if Microsoft could extend the Troubleshoot instructions behind this link https://aka.ms/yamlauthz which is included into the error message.
It seems that this scan-or-not-scan is specific to 'build' scripts 'azure-pipeline.yml' - that is why no such error appears in 'release' scripts.
