When I set an artifact to /var/lib/docker in a build job's properties, it's changed to a relative path
Unable to publish artifact [Docker Cache]: the source directory /home/bamboo/bamboo-agent-home/xml-data/build-dir/BB-THING-JOB1/var/lib/docker does not exist.
Never in any application should a path that starts with / be changed to a relative path. It specifically breaks making artifacts from global operating system cached files, and it also breaks reasonable expectations for relative files in a POSIX environment.
I was able to get the artifact published with a six ../ in a row, by changing the artifact path to: ../../../../../../var/lib/docker:
Publishing an artifact: Docker Cache
Finished publishing of artifact Shared artifact: [Docker Cache], pattern: [**/*] anchored at: [../../../../../../var/lib/docker] in 5s
Finalising the build...
However the problem surfaces later during deployment:
Preparing to download plan result BE-CORE-35 artifact: Shared artifact: [Docker Cache], pattern: [**/*] anchored at: [../../../../../../var/lib/docker] Unable to download artifact Shared artifact: [Docker Cache], pattern: [**/*] anchored at: [../../../../../../var/lib/docker]
Because of this bug, I don't see a way to use artifacts that are outside of the build directory unless they're manually moved inside it.
Workaround
- create a symbolic link to an external path inside your build directory.
![[Atlassian Documentation] Page](https://confluence.atlassian.com/images/icons/favicon.png "[Atlassian Documentation] Page"){kind=icon}
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page"){kind=icon}
[BAM-16970] Fix absolute paths for artifacts being changed to relative paths
I just ran into this issue with Bamboo version 5.15.3 build 51515. Can you update the affected versions field (and add a regression test perhaps)?
Thanks, I think I have already fixed it, I changed all my artifact definitions to remove the prefixed / and rebuilt, now the deployment downloads are happy again.
If anyone else has these sort of problems, look in the build artifacts, for missing artifacts, that was my clue that something was wrong.
Edit your bamboo.cfg.xml, change the build number to 51313. Then restart your Bamboo with an extra system variable -DUpgradeTask51314ConvertPathsInDownloadTasks=true .
Which version are you on and from which version did you upgrade?
Assuming this is the fix that broke all our build plans 
We have an artifact (a signing key) in the root directory of the repository. It was referenced as /signing.key
It can no longer find this artifact since upgrading, and the deployments now fail at the download artifact stage.
Workaround: create a symbolic link to an external path inside your build directory.
I'm sorry but after looking into our logs again, it's a problem of the shell task (when ran from an absolute path) and not the artifacts definitions.
The shell cwd is defined via a Bamboo var ```${bamboo.ourproject.SOME_PATH}```. Note that the absolute path still falls within the Bamboo working directory, it's just an abs path since it gets generated by a bash script.