In the plugin, jenkins fetches the path from

        if (Functions.isWindows()) {
            File applocaldata = new File(EnvVars.masterEnvVars.get("LOCALAPPDATA"));
            return new File(applocaldata, "Unity/Editor/Editor.log");

The path is correct according to http://docs.unity3d.com/Manual/LogFiles.html

It would be nice if someone could on a Windows 2008 x64 server run a cmd job that outputs the full environment to check what LOCALAPPDATA contains there.

In the mean time I suspect that specifying the full -logFile argument would help work around the issue.

Is it possible that Java has a different "bitness" than Unity? One 64 and one 32? What happens when you change the JRE Jenkins runs on to 32/64 bit (whatever it currently isn't)?

I made a test and installed a Windows 2008 SP2 64 bits server on EC2.

Installed java 64 bits on it (JDK7).

I started the slave as JNLP and ran it as a service.

Connected that server to my master, and sent it a simple job that runs a Windows batch command that does contains

set
java -version

Here's the relevant output:

ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Windows\system32\config\systemprofile\AppData\Roaming
BASE=C:\Jenkins
BUILD_CAUSE=MANUALTRIGGER
BUILD_CAUSE_MANUALTRIGGER=true
BUILD_DISPLAY_NAME=#3
BUILD_ID=2014-08-15_15-38-57
BUILD_NUMBER=3
BUILD_TAG=jenkins-unity3d-sample-project-lite-3
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
ComSpec=C:\Windows\system32\cmd.exe
DFSTRACINGON=FALSE
EXECUTOR_NUMBER=0
FP_NO_HOST_CHECK=NO
HUDSON_HOME=/Users/Shared/Jenkins/Home
HUDSON_SERVER_COOKIE=6fd210b99c2cb227
JAVA_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
JENKINS_HOME=/Users/Shared/Jenkins/Home
JOB_NAME=unity3d-sample-project-lite
LOCALAPPDATA=C:\Windows\system32\config\systemprofile\AppData\Local
NODE_LABELS=ec2-windows2008 windows2008
NODE_NAME=ec2-windows2008
OS=Windows_NT
Path=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Amazon\cfn-bootstrap\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 62 Stepping 4, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3e04
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
PROMPT=$P$G
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\AWS Tools\PowerShell\
PUBLIC=C:\Users\Public
SystemDrive=C:
SystemRoot=C:\Windows
TEMP=C:\Windows\TEMP
TMP=C:\Windows\TEMP
TRACE_FORMAT_SEARCH_PATH=\\winseqfe\release\Windows6.0\lh_sp2rtm\6002.18005.090410-1830\amd64fre\symbols.pri\TraceFormat
USERDOMAIN=WORKGROUP
USERNAME=WIN-I4XXXXXX
USERPROFILE=C:\Windows\system32\config\systemprofile
windir=C:\Windows
WORKSPACE=C:\Jenkins\workspace\unity3d-sample-project-lite

C:\Jenkins\workspace\unity3d-sample-project-lite>java -version 
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

I also tried starting unity from the same job and indeed, unity uses the SysWOW64 directory to store the Editor.log

So either a documentation bug, missunderstanding on how LOCALAPPDATA can be identified or bug in unity.

Anyway, I highly suggest you to override the -logFile in the meantime. I suspect that in the future I will even override the -logFile argument for all jobs and replace it with the plugin's one. This in order to solve other problems, including complexity in the plugin code and piping issues.

I reported issue #626407 @ unity

I would have implemented default -logFile argument if not for JENKINS-28567...

I just found this comment on the Wiki https://wiki.jenkins-ci.org/display/JENKINS/Unity3dBuilder+Plugin?focusedCommentId=73532468#comment-73532468

I've configured Global Configuration with location of Unity (custom path under "D:\Unity")

I've added a builstep to invoke Unity and passed command line arguments, including logfile and projectpath.

I get the following:15:09:33 FATAL: null
15:09:33 java.lang.NullPointerException
15:09:33 at java.io.File.<init>(Unknown Source)
15:09:33 at org.jenkinsci.plugins.unity3d.Unity3dInstallation.getEditorLogFile(Unity3dInstallation.java:121)
15:09:33 at org.jenkinsci.plugins.unity3d.Unity3dInstallation.access$100(Unity3dInstallation.java:35)
15:09:33 at org.jenkinsci.plugins.unity3d.Unity3dInstallation$3.call(Unity3dInstallation.java:112)
15:09:33 at org.jenkinsci.plugins.unity3d.Unity3dInstallation$3.call(Unity3dInstallation.java:110)
15:09:33 at hudson.remoting.LocalChannel.call(LocalChannel.java:45)
15:09:33 at org.jenkinsci.plugins.unity3d.Unity3dInstallation.getEditorLogPath(Unity3dInstallation.java:110)
15:09:33 at org.jenkinsci.plugins.unity3d.Unity3dBuilder._perform(Unity3dBuilder.java:104)
15:09:33 at org.jenkinsci.plugins.unity3d.Unity3dBuilder.perform(Unity3dBuilder.java:79)
15:09:33 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
15:09:33 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
15:09:33 at hudson.model.Build$BuildExecution.build(Build.java:199)
15:09:33 at hudson.model.Build$BuildExecution.doRun(Build.java:160)
15:09:33 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:585)
15:09:33 at hudson.model.Run.execute(Run.java:1684)
15:09:33 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
15:09:33 at hudson.model.ResourceController.execute(ResourceController.java:88)
15:09:33 at hudson.model.Executor.run(Executor.java:231)

The build works fine with same argument from the command line

After googling a bit, Windows XP doesn't have a LOCALAPPDATA. That was strange as Unity3d supports Windows XP.

So now the issue might be that I misread the http://docs.unity3d.com/Manual/LogFiles.html documentation. It is a bit confusing I think, as it seems that LOCALAPPDATA environment variable may not match the CIDL_LOCAL_APPDATA contents.

Yet we are assuming that LOCALAPPDATA is going to contain the proper PATH while we should really go for CSIDL_LOCAL_APPDATA.

A way to retrieve that value would be to use jna and
https://github.com/twall/jna/blob/master/contrib/platform/src/com/sun/jna/platform/win32/ShlObj.java#L54

See also http://stackoverflow.com/questions/585534/what-is-the-best-way-to-find-the-users-home-directory-in-java

Still in most cases, -logFile would be preferred, except for the issues (#JENKINS-28567) it might cause.

Code changed in jenkins
User: Jerome Lacoste
Path:
src/main/java/org/jenkinsci/plugins/unity3d/Unity3dInstallation.java
http://jenkins-ci.org/commit/unity3d-plugin/6859427102914f0906f68aa4317e43191b971e7b
Log:
JENKINS-24265: detect when environment variable isn't set. Point to issue and workaround

Code changed in jenkins
User: Jerome Lacoste
Path:
src/main/java/org/jenkinsci/plugins/unity3d/Unity3dInstallation.java
src/main/java/org/jenkinsci/plugins/unity3d/Win32Util.java
http://jenkins-ci.org/commit/unity3d-plugin/a7e66b6e3942f7e76c7cee8acf28216c9add5330
Log:
[FIXED JENKINS-24265] provide a proper detection of the %LOCALAPPDATA% directory on Windows based on Unity3d recommendation (look for CSIDL_LOCAL_APPDATA)

Code changed in jenkins
User: Jerome Lacoste
Path:
src/main/java/org/jenkinsci/plugins/unity3d/Unity3dInstallation.java
http://jenkins-ci.org/commit/unity3d-plugin/132fa331f43ea8e21e7448e67b95975d7ec2bba0
Log:
JENKINS-24265: document the unnecessary obsolete fallback code

I've tested this briefly on a Windows 7 JNLP slave. It requires more testing. If you have a computer which was affected by the previous behavior, feel free to report whether this now works or not.