I have been trying to do a GUI test with DUnit which includes interacting with modal windows via a message loop timer system by #tomazy (see my earlier question for more details: (How) Can I use FutureWindows with standard file open dialogs? ).
My solution in the other question works fine when I run the tests manually, but when I run this within a continuous build system in TeamCity, it hangs when the dialog's OK message should be handled. The service that runs the tests has the permission "interact with desktop" set, and I have verified that the hanging happens ONLY if the OK is pressed (i.e. the CDN_FILEOK notification happens). I can close the dialog using WM_CLOSE, but this naturally does not cause the dialog to return an OK modal result, and thus is not usable.
If I can't get this to work, I'll probably have to modify the production code (target of test) to publish an event to give the filename and have the test hook into it and give it without a dialog, but I'd like to know what is causing this problem and preferably of course solve it without modifying the production code.
Related
We have a TFS 2017 build agent executing a Visual Studio Test task to execute our unit tests. This has worked fine for several years, but all of a sudden - without any code changes - the task gets stuck.
All the tests have finished running, we see summary information, and it will sit at what appears to be the place where it would normally publish the results... but then nothing happens. We've waited 12+ hours for it to finish. This step normally takes about 90 minutes.
I've confirmed that the TRX file is being created. It's about 4MB in size. We're running a bit over 3000 unit tests.
I've also tried disabling code coverage and attachments upload inside the test task, but it doesn't appear to make a difference.
Below is a screen cap of the log output when the step is stuck.
Lastly, we have lots of other projects on this server whose tests run / publish fine, as well as TFS Releases for this same build that also run tests (integration/system tests) which work without issue.
UPDATE: We ran this build on a different build server, and it published tests correctly. So this means there is something wrong with this specific build server...
UPDATE 2: So I'm not longer sure what is happening here. The original build server we were having issues on is now working fine with no changes whatsoever. Just started working again. The other build server was working, and then stopped. Same issue. I broke up the 3000+ tests into two steps, roughly 50/50, and that worked a couple of times, but now does not. So this does not appear to be server specific, nor does it appear to be related to the quantity of tests. Debug logging offers nothing useful, as everything seems fine right up until it just stops doing anything after generating the TRX file.
UPDATE 3: Well, it's happening again. I'm not sure how to proceed. I even tried Fiddler on the build box to see if I could catch funky looking traffic, but most of the traffic I'd expect to see I don't. It's like a good chunk of the work isn't being captured (such as source downloads, reporting progress, or test result publishing) by Fiddler. Is it not over HTTP/HTTPS?
This was difficult to figure out due to the quantity of tests we're running, but I was able to narrow it down to a test that launched ping.exe:
[ExpectedException(typeof(TimeoutException))]
[TestMethod]
public void ProcessWillTimeout()
{
const string command = "cmd";
const string args = "/C ping 127.0.0.1 /t";
var externalProcessService = new ExternalProcessService();
externalProcessService.Execute(command, args, TimeSpan.FromMilliseconds(500));
}
For whatever reason, this test was leaving both conhost.exe and ping.exe "orphaned". The fact these processes were not terminating was, for an unknown reason, preventing the tests from publishing their results back to TFS. There is probably something somewhere that waits for the a process to finish and that was never happening.
Indeed, we would see a bunch of conhost.exe and ping.exe processes in both Task Manager and Process Explorer:
You'll notice the tool tip there... "[Error opening process]". I couldn't even use Process Explorer to kill these processes - although Task Manager could. Sure enough, when I killed them, the TFS build task would immediately resume and finish publishing results.
So there is clearly some kind of bug in that ExternalProcessService code we were testing (despite carefully having a finally block that terminated the process), but we are at least able to have our build tests run again without issue.
Suggest you abandon this build and trigger it again. To narrow down if this issue could be reproduced stably.
According to your description, all other builds work properly. And it worked fine for several years. All tests pass, the test report is written, but just the task hangs. Please double check if some other processes might possibly not be properly closing down.
Besides use another build agent to test again. Also try to create a newly build definition with the same settings, trigger that definition, this may do the trick.
Moreover, you could enable verbose logging for trouble shooting. To do this simply adding a build variable named system.debug and setting its value to 'true', this will contain a more detail log info.
I have a build which hangs in Jenkins. I have deconstructed the build down to a single windows command call, a directory change and a couple of echoes in an effort to isolate the problem. It would appear that the problem lies with a single call to a program executable (now the only call in my build). The build calls the program & then hangs for 30+ minutes (I cancel the build after this time) when it should take less than 1 second. Ordinarily I would be inclined to blame the executable or my misuse thereof, but for the fact that the same call (quite literally copied & pasted) in an ordinary command prompt works perfectly fine. Further muddying the waters is my knowledge of the fact that the build I'm trying implement is working just fine on another Jenkins server I know of, executable and all, and has never had an issue. I'm sorry I can't provide details on the executable in question but it's sensitive information. It may very well be the case that the executable is to blame, but the exact same call in three environments and only one hangs? What do you think?
More info on request.
So there I was, waiting for a reply when I decided to click on one of the "Related" topics on the right hand side. Lo and behold, there it was, a solution to my problem in answer to a different question. In short it goes like this:
Jenkins is a service. Services (on Windows) have a "Log On" account, of which the default appears to be "Local System". This had the effect of forcing (though I don't know why) my program out of quiet mode and thus hanging the build. Changing the "Log On" account to my own seems to have changed the behavioural relationship between Jenkins and the executable so that it now runs smooth and silent.
I am trying to Run a project in Xojo, which used to run okay previously.
Currently observed behavior:
Clicking "Run", has Xojo display various messages, including "Done Assembling Code".
Then, "Build Failed" dialog box flashes briefly. So briefly, I cannot even grab a screenshot.
And then it disappears, and no diagnostic error/warning messages are given.
I am new to Xojo. The project used to build okay. Something must have changed. Is there a way to somehow see what the problem is? Right now it looks like the IDE keeps on working but the Run process just dies, after barely flashing "Build Failed" Dialog Box.
I will consider it a successful answer if it helps or aids me in the direction of solving this issue.
Turns out the Debug folder was locked by another process. Releasing the lock, restored Run operation.
Where can I find crash reports?
Windows allows you to collect a Minidump when a crash occurs.
The procedure requires modifying a registry value using Regedit. You can also do so with the Xojo command Registry http://docs.xojo.com/index.php/Registry
See https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 for the exact procedure.
We have an app.exe that uses another 3rd party installation wizard app, InstallAnywhere, to install our application.
It is a text-based wizard - meaning a new shell is spawned (and the child process is executing some java.exe in order for its wizard steps to work) when
app.exe -i console
in the parent shell is executed.
Can pexpect be used in this case as a kind of question/answer interaction ?
We tried it with Hudson but it appears that Hudson can only monitor the parent process and not its child process. When Hudson job kicks off the python script, it starts but fails to begin at step 1 of the wizard - it hangs.
How can we overcome this ?
Thanks
If I'm reading this correctly, you want to interact with your executing installer (in this case, using pexpect) during a Hudson job, probably to do automated testing.
I'm thinking that expect may get you where you want to go if you call expect from a shell script (or batch file) that is, in turn, run from Hudson. The script would execute the tests, using your favorite flavor of expect, during which it either exits successfully or fails. Hudson would detect the failure, and you could then react accordingly. Your script, and any expect messages, would write to stdout, which Hudson would collect into your build log.
However, Flexera has a testing framework that allows you to test an installer via JUnit. Look at the bottom of this page. Or check out the JavaDocs.
This might give you more precision than an expect hack. You might even be able to write a Hudson plugin and do way with expect and shell scripts completely.
Update: after looking over the Javadocs, I found that the main class GUIAutomationFixture uses Java's Robot class. This means you probably won't be able to run this class on a headless server. You'll likely need either Windows, or a Linux/Unix box with a working X system.
I've got a custom ant script for building and other fun stuff. IntelliJ has very nice integration for handling Ant tasks. However, every time I run a task IntelliJ opens the script in my editor panel. It moves to the line of the task I'm running and then I close it; actually I now have it in its own panel, minimized to the max.
Is there anyway to disable this behavior? I just want the Ant script to run the task, pop up its own panel with some feedback (which it does) and then allow me to keep coding without having to close the script. Please tell me this is possible.
Man, I can't believe this only had 4 views, and two of those were me. Pretty weak.
Anyways, I've got a solution that might help someone else down the road. In the Messages window that pops up when the ant build starts there is an Auto Scroll to Source button. Make sure this button is unchecked.