Community
Participate
Working Groups
I am running 2.2.1 and I am setting HUDSON_WORKSPACES environment variable to a dedicated path. I am getting workspace paths like these: [HUDSON_WORKSPACES]/[JOB]/workspace I am expecting paths like this: [HUDSON_WORKSPACES]/[JOB]/ Note that HUDSON_BUILD environment variable is working as expected. When I set it to a distinct root, I do not get an extra "builds" folder in the job folder.
I don't agree. The way HUDSON_WORKSPACES works is good, HUDSON_BUILDS on the other side makes a mess because it stores files outside of the project folder. The builds consist of the builds itself, normally in the builds directory and symlinks to the lastStable and lastSuccessful builds outside of the builds directory. And at least the old Maven 2 module stores Maven modules outside of the builds directory too. See bug 398310: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398310
> The way HUDSON_WORKSPACES works is good Can you back up your position by describing at least one usecase for the extra folder level? Shortening the path, on the other hand is extremely beneficial for cases where max path length is an issue. The bug that you reference describes issues where some resources are placed incorrectly, but it does not follow that the solution is to add an extra folder level. Those resources could just as easily be placed in the existing project folder. An extra folder level would serve no purpose.
(In reply to comment #2) > The bug that you reference describes issues where some resources are placed > incorrectly, but it does not follow that the solution is to add an extra > folder level. Those resources could just as easily be placed in the existing > project folder. An extra folder level would serve no purpose. My point was that there is no correct place for those incorrectly placed links without a builds directory inside of HUDSON_BUILDS/<job name>. Without setting the HUDSON_BUILDS and HUDSON_WORKSPACES variable everything ends up in the jobs directory. The structure looks like this: <job name>/config.xml /nextBuildNumber /workspace/ /builds/ /modules/ (from Maven 2 modules) /lastStable /lastSuccessful The builds directory contains only the builds, but not the lastStable/lastSuccessful links. In addition to that, the Maven 2 module used to add a modules directory parallel to builds. We stopped using Maven 2, therefore I don't know if that's still an issue. The Maven 3 plugin doesn't do that. But maybe other plugins behave the same way? Configuring the HUDSON_BUILDS variable does not only move the content of the builds directory to the directory HUDSON_BUILDS/<job name>/ but also the lastStable/lastSuccessful links to the HUDSON_BUILDS/ directory. And the content of the modules directory is moved to HUDSON_BUILDS/ too. One way to fix this would be to create the same structure under HUDSON_BUILDS as you have under the jobs directory without the variable set. Basically, put the builds in the builds directory as they are without the variable set. The other solution would be to move these symlinks to HUDSON_BUILDS/<job name>/ and don't add a builds directory. But then they wouldn't be on the same level as they are without the variable. You would have to create the lastStable link pointing to e.g. build/123 without the variable and as pointing to e.g. just 123 with HUDSON_BUILDS set.
It would make sense to have everything related to builds under the builds directory. Since builds have systematic timestamp naming, there is no risk of conflicts. To avoid inconsistency of with/without variable set, the same approach could be applied in both case. I don't understand why nextBuildNumber, lastStable and lastSuccessful aren't already in the builds directory. HUDSON_BUILDS/[JOB]/[BUILD1] [BUILD2] [BUILD3] nextBuildNumber lastStable lastSuccessful [JOB]/builds/[BUILD1] [BUILD2] [BUILD3] nextBuildNumber lastStable lastSuccessful
Actually, nextBuildNumber should live next to job config. You want to be able to safely blow away the builds folder and losing nextBuildNumber would not be good.
I just think that my suggestion is easier to implement and therefore has a higher chance of getting fixed and a smaller chance of introducing new bugs. In the end, do you really want to fix the Maven 2 plugin or accept that some plugins don't work in a HUDSON_BUILDS configuration just to save one single directory? And I've added a comment to this bug because just removing the workspace directory (which doesn't hurt) and not caring about the mess that actually does exist in the HUDSON_BUILDS directory would be the wrong way to solve that. IMHO. And 100% agree about the nextBuildNumber. But this file stays in the jobs directory anyway and is not moved to HUDSON_BUILDS.
