Unit tests fail in Jenkins, but pass everywhere else

[TC]

I am new to Jenkins. I installed it today on a Windows 10 computer to automatically build (using the MSBuild plugin) and run unit tests (using NUnit Console as a batch command) on my .NET solution. Almost everything works perfectly, but I have been unable to solve one frustrating problem, despite working on it for hours:

One unit test project fails, but only when run from Jenkins. I can run the same unit tests from anywhere, logged-in as anybody, and they pass.

In an attempt to debug the problem, I created a new account called "Jenkins" and configured the Jenkins service to run under that account. I have configured my Jenkins project to execute "whoami" as a Windows batch command, and verified that Jenkins is running as the "Jenkins" user. I have verified that the "Jenkins" user can run the unit tests without error. I have logged-in as myself, used "runas" to impersonate the "Jenkins" user, and verified that the unit tests pass under those conditions also. Yet somehow when Jenkins runs the same tests as the same user, the tests fail.

So my question is: What does Jenkins do differently when it executes a Windows batch command that could explain the failure? Because the unit tests run successfully outside of Jenkins, and only fail inside Jenkins, I think I can crack this problem if I just know more about the runtime environment Jenkins creates.

About the error itself:The failing tests all automate Excel. The error reported by Excel is "Microsoft Excel cannot open or save any more documents because there is not enough available memory or disk space". Posts on the internet generally say this message indicates a DCOM security problem (and has nothing to do with memory or disk space). Giving the user sufficient privileges to launch, activate, and access Microsoft Excel applications should solve the problem. I've done that, giving the "Jenkins" user full permission on Excel applications, yet the error persists.

All advice is appreciated.

-TC

[Slide]

Is your Jenkins running as a service? If it has to open Excel and is running as a service, this can be an issue. You need to give the service the ability to interact with the desktop. I believe this is in the service settings, but you can Google and find information if it is not right there.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/db1129ea-84dd-41ea-8349-8a887fa85853o%40googlegroups.com.

[TC]

Yes, Jenkins is running as a service. However, I have created a user account named Jenkins and I run the service on that account. I have verified that the Jenkins user account can run the unit tests successfully. I don't know what else is required to "give the service the ability to interact with the desktop". I have scoured the DCOM and service configurations, and I've experimented with all settings that seem possibly relevant, yet nothing works.

Actually, one thing works: In the DCOM configuration, there is a way to tell the system to always run Microsoft Excel applications as a specific user. I have told it to always run Excel as the Jenkins user. I don't know why this makes a difference because the Jenkins service is already running everything as the Jenkins user, yet this somehow suppresses the error. I am using this workaround for now, but I regard it as a kludge, and not as an acceptable long-term solution.

With a little speculation, I think I can answer my own original question:

Q: What does Jenkins do differently when it executes a Windows batch command that could explain the failure?

A: Jenkins doesn't do anything differently, per se, but is running as a service, and when Windows decides what is allowed to happen on a computer, it doesn't just consider the user privileges; it also considers whether or not the commands were issued by a service. Microsoft Excel and other COM applications, in particular, seem to be off-limits to service-issued commands even when fully accessible to the user issuing the commands.

Thank you, Slide, for your reply, and thanks to all others who read and considered my question. I am going to set this problem aside for now and come back to it later when I have spare time and possibly a fresh perspective.

-TC

To unsubscribe from this group and stop receiving emails from it, send an email to jenkins...@googlegroups.com.

[Slide]

Take a look at this article on how to enable a service to interact with the desktop. 

https://www.ibm.com/support/knowledgecenter/SSGR73_7.5.1/com.ibm.wci.live.doc/Secure_Connector/enablinginteractivemodeforwindowsservices.html

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/f6a31dd1-ff14-41af-8a64-ccf0ecde70d1o%40googlegroups.com.