-
Improvement
-
Resolution: Not A Defect
-
Major
-
Linux
When you create a folder with spaces in the name, and then add a Maven job to it, in some cases the build will fail (e.g. when the Maven project uses plugins to generate sources, such as the jaxws-maven-plugin) because Maven calls a command that is incorrectly parsed by the shell because of spaces in the path.
What I would suggest is that the underlying directory for a Folder be created using a numerical name rather than the name of the folder entered in the Jenkins UI. This would prevent any issues with spaces or other special characters used in the folder name, plus it would help shorten the directory paths as well. I reckon the easiest way to generate the directory name for the folder would be to calculate the SHA1 or MD5 hash for the folder name and use that as a the 'physical' underlying directory name.
The Jenkins UI would go on displaying the 'logical' folder name asc usual, but should also indicate the associated 'physical' underlying directory name associated to the folder so that administrators could know where to locate the folder under the jobs/ subdirectory.
Note that is issue is not specific to Folders in Jenkins, it also affects Jobs since the directory created for a job is based on the job name as well... So really this issue should be treated both at the folder and job level I suppose...
(Also note that other build systems such as Continuum are not affected by this problem precisely because they use sequential numbers for creating build directories instead of using the name of the project or the project group).
Of course, the easy workaround is NOT to use spaces in job or folder names but then it's a bit limitative not to be able to name jobs/folders as you wish and uses spaces or other special characters to enhance legibility..
Just my humnle opinion...
Regards
Laurent
PS - Edited to add affected components: "maven", "core", "cloudbees-folder" – please feel free to change affected components since I'm not sure these are the right categories to use
[JENKINS-20600] Build issues when folder name (or job name) contains spaces
As designed. Any Maven plugins (etc.) which do not work when run inside a project path containing a space are simply broken. (Has no one ever tried running them inside C:\Documents and Settings\Poor Spacey User\My Maven Projects?)
I agree there's a straightforward workaround, but it's wrong to say this is "Not A Defect". This is still a bug, albeit a minor one. Could this be reopened, possibly with a much lower priority than before?
gregoryfong_vg I do not agree this is a bug at all. Jenkins uses the full name of the folder + job in the workspace path. If your projects have bugs in their build systems preventing them from being built in directories which contain certain characters such as spaces, you should not use those characters in folder or job names (and you should consider configuring Restrict project naming to make sure no one forgets); you can feel free to use any wild characters in display names.
jglick Our build system handles spaces just fine. The issue I was finding was when passing in the ``--strip-path $WORKSPACE`` with the coverity plugin. There doesn't seem to be any good way to quote or escape the contents of "$WORKSPACE" such that it will work properly, though thinking about it more I'm not quite sure this is an issue with how jenkins passes things to the coverity plugin or with the coverity plugin itself.
The rationale for calling this "as designed" feels pretty weak to me. We're working in an Ubuntu environment where all of our development machines don't have spaces in the project directory, and multibranch pipeline jobs in Jenkins work just fine even with spaces in the job name or in containing folders. However, when we try creating a pipeline job (not multibranch), suddenly we run into errors due to spaces or other special characters. We're working around this by not using those characters in the job name and instead using the "Display Name", but it still limits our ability to have such jobs in certain folders and also messes up things like alphabetical ordering of jobs.
Should the scripts in our repo be more robust to handle spaces in absolute file paths? Sure. Should we be forced to make those updates at a critical stage in the project just because Jenkins insists on a behavior that isn't even consistent across different job types? Absolutely not.
In our context, this is an automated tests job for a proprietary product so it isn't like we're going to be shipping this code to customers and we have full control of where it executes.
It should be possible to fully separate the workspace directory path from the job name and any containing folder names. I feel like this used to be possible with specifying custom workspace directories.
C Hedge
added a comment - - edited The rationale for calling this "as designed" feels pretty weak to me. We're working in an Ubuntu environment where all of our development machines don't have spaces in the project directory, and multibranch pipeline jobs in Jenkins work just fine even with spaces in the job name or in containing folders. However, when we try creating a pipeline job (not multibranch), suddenly we run into errors due to spaces or other special characters. We're working around this by not using those characters in the job name and instead using the "Display Name", but it still limits our ability to have such jobs in certain folders and also messes up things like alphabetical ordering of jobs.
Should the scripts in our repo be more robust to handle spaces in absolute file paths? Sure. Should we be forced to make those updates at a critical stage in the project just because Jenkins insists on a behavior that isn't even consistent across different job types? Absolutely not.
In our context, this is an automated tests job for a proprietary product so it isn't like we're going to be shipping this code to customers and we have full control of where it executes.
It should be possible to fully separate the workspace directory path from the job name and any containing folder names. I feel like this used to be possible with specifying custom workspace directories. c32hedge multibranch Pipeline jobs use a specialized workspace allocator since otherwise workspace paths would often become unreasonably long, or include very dangerous characters like / or #, and in that case you have no way to control the job name other by enforcing onerous restrictions on SCM usage. This system could potentially be extended to any job; currently you can enable it for all jobs by running with -Djenkins.branch.WorkspaceLocatorImpl.MODE=ENABLED (default is MULTIBRANCH_ONLY). Alternately, you can just use the dir step to select some other directory in work in, as a workaround for build systems which do not tolerate spaces and the like.
You already have the following two options:
Given those (you mention neither), is this really a problem?