Jump to: navigation, search

My software builds on my computer but not on Hudson

Revision as of 18:57, 14 December 2012 by Scott.fisher.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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 Hudson, please go through the following check list.

PATH

Especially when you run Hudson 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 Hudson is seeing, go to http://server/hudson/systemInfo and scroll down to see the environment variables.

Each slave also gets different environment variables, depending on how it's started. To check their respective environment variables, visit http://server/hudson/computer/COMPUTERNAME/systemInfo.

Network drive mappings (Windows)

On Windows, network drive mappings are scoped to users. So if you run Hudson 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.

Desktop access (Windows)

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 Hudson and slaves as Windows services via Hudson's GUI, this flag is set by default.

Windows Service Settings

If you get the following error:

fatal error C1902: Program database manager mismatch; please check your installation

then you should try changing the "Log on" user for the Hudson service. For Visual Studio projects, Hudson will fail to build the project if running as service. This problem is caused by Hudson 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.

Project Name

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 Hudson JIRA issues reported but not duplicated about other special characters causing problems too.