[JENKINS-53666] Warn when cloud configuration requests volumes including FS root

oleg_nenashev and I were troubleshooting a user's installation which was using the Docker cloud and in which sometimes concurrent builds wound up writing over each other's workspace, causing build failures. It turned out that in his cloud configuration, the remote FS root /home/jenkins was being mounted as a volume (/home/jenkins:/home/jenkins), and so in fact every agent was using the same FS root, and unknowingly using the same workspace /home/jenkins/workspace/jobname even for concurrent builds.

There ought to be a form validation warning when you try to do this. The volumes textarea should also have some discussion of the impact of actually using this option. The same user was also mounting a directory containing common build tools (rather than baking these into the image), which is unlikely what he really wanted, since such a mount would constrain where the Docker daemon could actually schedule containers to run.

---
Originally reported by jglick, imported from: Warn when cloud configuration requests volumes including FS root

• status: Open
  
• priority: Major
  
• component(s): docker-plugin
  
• label(s): concurrent-build, volumes
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 1
  
• imported: 20260709-204134
  

Raw content of original issue

oleg_nenashev and I were troubleshooting a user's installation which was using the Docker cloud and in which sometimes concurrent builds wound up writing over each other's workspace, causing build failures. It turned out that in his cloud configuration, the remote FS root /home/jenkins was being mounted as a volume (/home/jenkins:/home/jenkins), and so in fact every agent was using the same FS root, and unknowingly using the same workspace /home/jenkins/workspace/jobname even for concurrent builds.


There ought to be a form validation warning when you try to do this. The volumes textarea should also have some discussion of the impact of actually using this option. The same user was also mounting a directory containing common build tools (rather than baking these into the image), which is unlikely what he really wanted, since such a mount would constrain where the Docker daemon could actually schedule containers to run.