It'd be nice if this actually documented where the file ends up, and what environment variable the path of said file is bound to!
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
I found it in this location; hope this helps:
../../../../../opt/vsts/work/_temp/
Hi @maudormiston and @bryoncline, according to the JSON settings here, the path is set to an environment variable defined as "secureFilePath".
This is supposed to be set to an environment variable but is being mangled into a long hex-name for some reason.
2018-03-01T12:12:30.2875816Z Name Value
2018-03-01T12:12:30.2876814Z ---- -----
2018-03-01T12:12:30.2884607Z 8504415A9DC43BDA7F65501AA43... D:\a\_temp\Example.secret
It's odd, isn't it?
I ended up just using a marketplace add-on with the same name which quite sensibly lets you set where you want the file to go.
I have no idea what the intention was with prefixing that long hex string, it's certainly not helpful!
Much neater than my solution (((gci env:*) | where { $_.Value -like "*Example.secret*" }).Value)
To avoid having the hash, you can set the reference name for the task in the UI:

Then the variable will contain the reference name instead of a generated hash.
Thanks,
Madhuri
Thanks Madhuri,
I'm having trouble finding an example of setting a reference to a task output in yaml
I've tried setting the name for the task, but that appears to stop any environment variable from being created with the secureFilePath as the value:-
- task: DownloadSecureFile@1
displayName: Download Secure File
name: secureFile
inputs:
secureFile: secure.file
One observation I have made is that when you use the DownloadSecureFile task from yaml and don't specify a name the environment variable is called 'DOWNLOADSECUREFILE_SECUREFILEPATH' consistently.
- task: DownloadSecureFile@1
displayName: Download Secure File
inputs:
secureFile: secure.file
Interestingly if you have more than one DownloadSecureFile task then the environment variable names change to 'DOWNLOADSECUREFILE1_SECUREFILEPATH', 'DOWNLOADSECUREFILE2_SECUREFILEPATH', etc
- task: DownloadSecureFile@1
displayName: Download Secure File
inputs:
secureFile: secure.file
- task: DownloadSecureFile@1
displayName: Download Another Secure File
inputs:
secureFile: secure.file
I have raised a PR on this to allow a custom directory to be optionally specified as I don't feel the environment variable is a reliable method
@steve-hawkins: The behavior you are seeing for YAML is what we expect for a build definition created in the UI as well. In YAML the reference name is the same as the taskName and cannot be changed. So you should see variable being set as DOWNLOADSECUREFILE_SECUREFILEPATH if there is one task. I see the same in my non-YAML build definitions created in the UI as well. Can you verify if you still see a hash in the output variable names. If reference name is not set, you should see predictable values generated that you can rely on in scripts.
If you continue to see the hash, please share your build definition json so we can investigate.
One reason we didn't want to allow downloading the secure files to a different location is to ensure they are cleaned up. I will review your change with our product manager internally and get back to you on the PR.
Thanks,
Madhuri
I'm having trouble referring to a secure file in my Maven task.
I've uploaded a secure file "settings.xml" and named the reference "maven_settings_xml" ... giving a variables list reference of "maven_settings_xml.secureFilePath".
Tried using this in my Maven task OPTIONS
{code}
--settings $(maven_settings_xml.secureFilePath)
{code}
Initially starts downloading artefacts correctly using the file...
{code}
2018-03-15T05:32:35.9074347Z [command]C:\Windows\system32\cmd.exe /D /S /C "C:\java\maven\apache-maven-3.2.2\bin\mvn.bat -f D:\a\1\spom.xml help:effective-pom --settings D:\a_temp\settings.xml"
... but then there's an attempted COPY (no idea why) and the reference path is badly interpreted.
Note sure if this is a problem with the Maven task or the secure file location, or a bit of both
{code}
2018-03-15T05:36:47.9476050Z cp: no such file or directory: D:\a\1\s\D:\a_temp\settings.xml
2018-03-15T05:36:47.9476297Z
2018-03-15T05:36:47.9476728Z
2018-03-15T05:36:47.9557287Z ##[error]Failed cp: cp: no such file or directory: D:\a\1\s\D:\a_temp\settings.xml
2018-03-15T05:36:47.9569311Z
2018-03-15T05:36:47.9571826Z SYSTEMVSSCONNECTION exists true
2018-03-15T05:36:47.9584141Z [command]C:\Windows\system32\cmd.exe /D /S /C "C:\java\maven\apache-maven-3.2.2\bin\mvn.bat -f D:\a\1\spom.xml -s "C:\Users\BUILDG~1\AppData\LocalTemp\settings.xml" clean package deploy -Pdev "-Dci.username=wescef_continuous_integration" "-Dci.password=**" -DskipMunitTests"
2018-03-15T05:36:50.3642015Z [ERROR] Error executing Maven.
2018-03-15T05:36:50.3644236Z [ERROR] The specified user settings file does not exist: C:\Users\BUILDG~1\AppData\LocalTemp\settings.xml
2018-03-15T05:36:50.4038845Z C:\java\maven\apache-maven-3.2.2\bin\mvn.bat failed with return code: 1
2018-03-15T05:36:50.4061054Z Could not retrieve code analysis results - Maven run failed.
2018-03-15T05:36:50.4067076Z ##[error]Build failed.
{code}
@luke-munro: What you are seeing seems like a bug in the Maven task unrelated to the issue being discussed here. Can you please open a bug on https://github.com/Microsoft/vsts-tasks/issues?
Update: The bug is here: https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/Maven/maventask.ts#L184 (we should use path.reslove :()
As a workaround, you can add a script before the Maven task to copy $(maven_settings_xml.secureFilePath) to $(System.WorkingDir). That will eliminate the error you are seeing. Sorry about the roundabout workaround. We will fix the bug in Maven task.
Thanks,
Madhuri
I've added this information to the docs in this pull request
Most helpful comment
To avoid having the hash, you can set the reference name for the task in the UI:

Then the variable will contain the reference name instead of a generated hash.
Thanks,
Madhuri