[JENKINS-33762] Per-folder tool installations

Allow configuration of JDK at folder level.

• Removes the clutter of global configuration.


• Avoids the potential dependency on Jenkins Administrators for configuration changes.

Who in your organization would benefit from this new feature?

• Teams are managed on folder level. Therefore every team that uses Jenkins would benefit from self-managed configuration.

What would this person use this feature for?

• Configuration of JDKs of their own build nodes

Why is this necessary to accomplish your use-case?

• Global Jenkins configuration gets cluttered by a lot of S3, SSH/SCP, Java, and many more configuration.


• Users should not depend on Jenkins administrators for every configuration of a basic tool


• The Cloud is mainly self-managed. In AWS for example a global admin often provides the framework and permission. But in the end the users will be in charge of setting up their environment by spinning up EC2 instances or manage their S3 bucket and load balancer.


• Why can some configuration be done on a folder level (e.g. credentials), other configuration can be done in the job level (parameters, specific configuration) but others can't (s3 profile, definition of the JDK path (you can only choose in the global config available ones, but you can't define your own))?

Impact - what impact is the absence of this feature having on your organization?

• Delays for users.


• Frustration for users


• More questions for alternative build systems that provide some more freedom

Related Jenkins JIRA issues - if you already know of a related issue in the OSS JIRA, please link to it.

• N/A

---
Originally reported by owood, imported from: Per-folder tool installations

• status: Reopened
  
• priority: Minor
  
• component(s): cloudbees-folder-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 2
  
• imported: 20251211-141027
  

Raw content of original issue

Allow configuration of JDK at folder level.




	
Removes the clutter of global configuration.

	
Avoids the potential dependency on Jenkins Administrators for configuration changes.





Who in your organization would benefit from this new feature? 



	
Teams are managed on folder level. Therefore every team that uses Jenkins would benefit from self-managed configuration.





What would this person use this feature for? 



	
Configuration of JDKs of their own build nodes





Why is this necessary to accomplish your use-case? 



	
Global Jenkins configuration gets cluttered by a lot of S3, SSH/SCP, Java, and many more configuration.

	
Users should not depend on Jenkins administrators for every configuration of a basic tool

	
The Cloud is mainly self-managed. In AWS for example a global admin often provides the framework and permission. But in the end the users will be in charge of setting up their environment by spinning up EC2 instances or manage their S3 bucket and load balancer.

	
Why can some configuration be done on a folder level (e.g. credentials), other configuration can be done in the job level (parameters, specific configuration) but others can't (s3 profile, definition of the JDK path (you can only choose in the global config available ones, but you can't define your own))?





Impact - what impact is the absence of this feature having on your organization? 



	
Delays for users.

	
Frustration for users

	
More questions for alternative build systems that provide some more freedom





Related Jenkins JIRA issues - if you already know of a related issue in the OSS JIRA, please link to it. 



	
N/A