I have problems with creating a job in jenkins. At the "Build" step I select Build "execute windows batch command", where I want to start a browser such as opera, google chrome portable or firefox portable, the command never terminates.View screenshot
For IE, firefox and chrome I do not encounter any problems
If someone has a solution. thank you in advance
What do you expect? You have launched an executable that shows a form, albeit in a session that can never have a console session attached.
Jenkins, by design, will sit there until the executable terminates - which generally happens when the form is closed by a user interacting with it. Since there is no GUI, this process can only ever terminate if someone kills it with Task Manager.
What are you actually trying to achieve? There's almost certainly a reasonable way to do it.
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.
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 am using Jenkins to run a Maven project having Junit tests in Sauce Connect. I created a job and to stop/abort the build in between I clicked the Cross button (X) shown near progress bar for build execution. But the build execution does not get stopped.
When I moved to console output for the build, it was showing message as "Closing Sauce Connect" and it takesd too much time and Jenkins does not stop build process.
Could anyone please advice as to how can we manually stop/abort build execution.
Additionally, is there any site where we can find proper documentation regarding Jenkins for Beginners as i have few more problems regarding its start and stop process.
I guess it is too late to answer but my help some people.
Install the monitoring plugin. (http://wiki.jenkins-ci.org/display/JENKINS/Monitoring)
Go to jenkinsUrl/monitoring/nodes
Go to the Threads section at the bottom
Click on the details buttom on the left of the slave the job is build on
Sort by User time (ms)
Then look at the name of the thread, you will have the name and number of the build
Kill it
Hope it can help
Jenkins will terminate the build nicely, i.e. wait for the running processes to end after sending the termination signal. If the processes take a long time to terminate, it will wait. The easiest way is to change your build/code such that it terminates immediately, or has a timeout for closing connections etc.
Regarding more documentation, have a look at the Jenkins wiki or get the Jenkins book.
When connecting to a remote TFS 2010 installation via my Visual Studio 2010, Process tab of Build Definition freezes. Everything seems to be disabled. Is there any work-around?
UPDATE 1:
By freezing I mean:
I can navigate to all tabs: General, Trigger, Workspace, Build Defaults, Process and Retention Policy. Except for Process tab, they all are working as excpected. When I click Process tab, it is showed, but none of parameters are shown, and the tab itself is in gray. Actually nothing could be clicked. It is like that Visual Studio is waiting for something to be completed or loaded.
UPDATE 2:
I have explored that when I leave Visual Studio alone for a long time about 20 or 30 minutes, the Process tab goes normal. That means all parameters appears and can be edited. That seems downloading or getting something from server causes this very very long delay.
You might want to check out exactly what rights you have on that server with regards to administrating builds.
http://intovsts.net/2009/09/03/more-fine-grained-permissions-in-tfs2010/ and
http://msdn.microsoft.com/en-us/library/ms252587.aspx
I think one of the main ones is "edit build definition"
If you don't have rights, then there won't be a workaround.
UPDATE:
The only things I can really think of at this point is to put a sql monitor on the TFS Database and possibly, watch the network traffic to see how the network interface is being used.
It's possible that something is wrong on the database server causing a huge amount of load. The other possibility is that the network is badly configured and running at 1Mb instead of 100Mb+.
Beyond those, I'd say call MS Support and open a trouble ticket. This is by no means normal and is likely indicative of some underlying hardware or installation issue.
Afsharm,
Happend with me too. This happened when i had the build defination open on one VS instance in edit mode and i opened it for editing on another pc. After a while it errored saying "TFS 20391: Locked for blah blah..." I had to close my visual studio instance on both the machines and restart, it worked there after. These are very occassional cases and very hard to replicate. I would suggest restarting your visual studio session and trying again.
PS - Worth checking if some one else have the process template open for edit as well?
HTH.
Cheers, Tarun