Often, your build is sensitive to the environment in an unintended way and that causes a build failure. So before you suspect a bug in Jenkins, please go through the following check list.
Especially when you run Jenkins as a service/daemon under a different user account, it often gets a different PATH environment variable than your shell does, and this results in failing to find some commands, or invoking different versions of the same commands. To check what environment variables Jenkins is seeing, go to http://server/jenkins/systemInfo and scroll down to see the environment variables.
Many tools also change their behaviours on the values/presence/absence of some environment variables, so you might want to check those, aside from PATH.
Each slave also gets different environment variables, depending on how it's started. To check their respective environment variables, visit http://server/jenkins/computer/COMPUTERNAME/systemInfo.
Tools often read per-user configuration files, and therefore, they can be reading different values when you run it from your shell vs when you run it from Jenkins. The best way to verify this is to login as the same user as Jenkins. See How to get command prompt as the SYSTEM user, and on Unix, see su/sudo.
On Windows, network drive mappings are scoped to users. So if you run Jenkins in a different user account (such as a Windows service), they will not see the same drive mapping that you do. Use UNC notation (//server/path/to/file), or refer to How to get command prompt as the SYSTEM user and start a command prompt, then define drive mappings.
On Windows, processes started as services do not have access to the Window station (unless "interactive" option is set for this process), and such processes cannot perform certain GUI-related system calls. This can affect your tests if your program involves GUI.
The access to window station is inherited through the process chain, so for example, if you have a Cygwin ssh daemon running as a non-interactive service, a slave launched via ssh will not have the window station access. If you suspect you are seeing this error, go up the process tree, find the root service process, and enable the interactive flag in the Windows service manager.
If you install Jenkins and slaves as Windows services via Jenkins' GUI, this flag is set by default.
If you get the following error:
then you should try changing the "Log on" user for the Jenkins service. For Visual Studio projects, Jenkins will fail to build the project if running as service. This problem is caused by Jenkins running under Local System Account (used for Windows Services). To fix this problem, edit service details and set "Log on" details to a different local user.
Spaces and special characters may cause build errors. On Linux with Maven it is possible to get classpath errors from Maven when the project name contains a space(e.g., "My Project"). A dash "-" seems to be a safe character instead of a space. There are also some Jenkins JIRA issues reported but not duplicated about other special characters causing problems too.
Skip to end of metadata Go to start of metadata