<< Back to previous view

[QB-2750] Additional Node Property/Setting
Created: 28/Jun/16  Updated: 03/Aug/16

Status: Closed
Project: QuickBuild
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: J. Mash Assigned To: Robin Shen
Resolution: Won't Fix Votes: 0
Remaining Estimate: Unknown Time Spent: Unknown
Original Estimate: Unknown


 Description   
This is a request to add a 'workspaceRoot' property to the 'node.properties' file.

The idea behind this request is to allow a means of globally defining / overriding the default workspace root for the node. This improvement would better support custom node configurations, such as having a separate drive subsystems with different backup, security, and virus scanning policies dedicated to different purposes (in our case, one drive subsystem is dedicated to the workspace). This would also allow the workspace root to be changed in one location on the node and have it apply globally with no further changes.

This can be emulated with environment variables or user attributes, but introduces a much larger maintenance concern as a result -- In this scenario, changing the workspace directory requires changing the value of the environment variable / user attribute along with *all* of the places it is referenced. This is how we currently manage it, but there have been some cases where bugs were introduced due to missing a location where the environment variable / user attribute was referenced, and in some cases remained a latent bug for many days until the node in question entered the rotation.

This seems like it would be reasonably simple to add, but provide a HUGE benefit to us in our case as we manage roughly 90 build nodes of varying drive configurations.


 Comments   
Comment by Robin Shen [ 29/Jun/16 01:00 AM ]
In advanced setting of the root configuration you may change workspace setting to use specified workspace path as below:

${node.hasAttribute("workspaceRoot")?node.getAttribute("workspaceRoot")+"/"+configuration.pathName: system.getWorkspaceDir().absolutePath + "/" + configuration.pathName}

Then you can define workspaceRoot attribute for the node you want to override the default workspace root.
Comment by J. Mash [ 23/Jul/16 12:09 AM ]
This is essentially what we are doing as a workaround, however... It feels quite wrong to have to resort to this as a means of configuring the location of QuickBuild's workspace directory for all configurations for all products. This seems very much an application-level setting that should live in the application's configuration file(s).

Consider it similar in nature and scope to being able to specify where QuickBuild's "logs" directory lives, or the "storage" directory.
Comment by Robin Shen [ 23/Jul/16 03:57 PM ]
I understand this is a workaround, but we do not want to get QB setting page piled with possible options and settings for different scenarios. We try to keep simple things easy while make complex things possible.
Comment by J. Mash [ 23/Jul/16 04:43 PM ]
This really has little to do with the settings page at all, as it would be a node-specific setting that lives in the 'node.properties' file. I really don't understand the resistance here, as it's completely hidden for those who don't care about it, and exists for those who need it.
Comment by Robin Shen [ 24/Jul/16 01:32 AM ]
Simply adding a "workspaceRoot" property to the node.properties does not do the work at all, as user may have deleted/renamed that unintentionally if it is mixed with other properties. So it should be handled in a different way from other properties, and this means you have to add extra setting at node level to complicate things for most users not using that at all.
Comment by J. Mash [ 03/Aug/16 06:27 PM ]
I wholly disagree and fail to see how adding an optional configuration property that defaults to the existing behavior complicates anything for most users. If the default behavior doesn't change, most users will never even notice anyway. I also challenge the perception that this is something "most users" wouldn't use, simply due to this feature's prevalence in just about every other CI/CD tool available, with Jenkins/Hudson being the classic and most prominent example.
Generated at Sun Oct 05 21:28:25 UTC 2025 using JIRA 189.