I have a build running in TeamCity, with only one build step: launching a BAT file. TeamCity sometimes kills my build with a (double) keyboard interrupt, and I have no idea why. The output at the end of the build is like this:
Running build failed.
Error:
NUnit test failed (7).
Starting BuildFailureTarget: recover
Uninstalling service under test..Terminate batch job (Y/N)?
^C
Process exited with code -1073741510
This build runs some integration tests via NUnit, after installing a Windows service, with a SQL database. If any of the tests fail, the build script (which uses FAKE, F#'s Make) runs some cleanup—uninstalls the service, tears down the database. It's the same cleanup code that runs when the build passes, only the target name is different (recover). It seems that TeamCity only kills the build when some tests have failed. I should note that the message "Uninstalling service under test" is from a subprocess which is running the uninstaller. This still happens even if we turn off several failure conditions such that the build (spuriously) passes after several tests fail (we are not using Java, so we assume that one is irrelevant):
I can't figure out why TeamCity is killing my build before it is done. How do I figure out what would cause TeamCity to issue this interrupt?
It seems that TeamCity does this if it detects dangling processes (not sure how to be more precise about that). What we had happening was that an exception was being thrown by a third-party library while we were running a subprocess, before the code that stopped that process. The exception was handled, and the cleanup that got triggered by the exception would have resulted in the process getting shut down anyway (through another means), but before that cleanup was finished, TeamCity was killing our build: which ironically meant that the process never did get shut down.
Our solution was to catch the exception and ensure the first shutdown code got called before failing. Ultimately we were not able from a TeamCity side to get more clarity on what was happening: we found the bug by careful analysis of our code. However it seems that this happens when standard cleanup logic for subprocesses fails.
Related
Is it possible to stop a gradle build gracefully, meaning without throwing an exception? It is not
System.exit() as this kills the daemon
throw SomeException
Background: for occasional debugging I want to run some method after the build is set up and show some information, but then stop and don't actually run the build. Throwing an exception for some debugging situation is probably good enough, but without the exception it would be even nicer.
I have multiple existing projects which build fine. They run MSBUILD on a windows agent running the windows service.
I wanted to create a single project that builds them all in a particular order and collects the artifacts from all of them. I decided to try creating a pipeline. When I run it it gets to the first build statement and then just hangs there, no error it just says "Scheduling Project:.." and the little wheel spins forever. The job its trying to start normally finishes in a few seconds.
stage('job1'){
node('windows'){
build job:'job1', quietPeriod: 0, wait: true
}
}
I have to kill the build manually, it never starts the job.
Ok I managed to rearrange things so that the pipeline runs on the master and the individual jobs and artifact copies run one at a time on the slave, its working now.
I have a gitlab runner installed on one of my test servers.
I want to build and deploy my app on every commit.
The server is a windows server and the app is a .net core 1.1 app.
my build script works fine but eventually it runs dotnet MyApp.dll which obviously makes the pipeline stop wait until it finishes (but, of course, my app won't finish, I want it to run..)
I tried running start dotnet MyApp.dll but that still doesn't work as gitlab's runner won't stop running until all of it's child processes exit.
I am certain I'm using gitlab's CI in a non idiomatic way but fail to understand how to deploy locally correctly.
Any suggestions?
Windows doesn't offer any easy way to disown a process and you probably don't want to task yourself with stopping the process on your next deploy. What you should do is use SRVANY.EXE to create service out of your application and then use the Gitlab CI to stop the service, replace the files and run it again. It's been a while since I used Windows so I'm sorry but I can't provide the exact commands to run.
I have a set of Java GUI tests on Windows that sometimes fail to cleanup a file or a window due to a lock. The next time any test starts I get a "Failed to start build #XXX on agent" message. The build then fails very quickly on that agent, which frees the agent to run another build and this results in a lot of builds failing with the same message on the same agent.
Is there a way to disable the agent when the problem occurs and maybe send a notification?
Rather than disabling the agent, you could try cleaning the files which get locked. Try using Swabra (Build Files Cleaner)
We've recently found that an acceptance test project fails occasionally on our build server- due to our web drivers Type is not resolved error. I'm trying an experiment to see if its a question of timing of build steps. To this end I've tried to create a separate build step which launches the webdriver executable separately and then proceed onto the unit tests - the issue I have is when I launch the process it blocks the next step after it has successfully started.
eg. Type is not resolved for member 'OpenQA.Selenium.WebDriverException,WebDriver, Version=2.41.0.0, Culture=neutral, PublicKeyToken=null'..
Is there a way I can progress to the next build step after I call an exe?
Thanks
Do you have multiple build agents? Have you considered splitting this into separate build configurations and having triggers on previous build configurations?
You could have configurations:
Compile,
Webdriver, triggered on successful compile completion
Unit Tests, triggered on successful compile completion.
It's not nice, but it should give you the non-blocking behavior you're after. I can't see any other way of making it happen, build configurations are supposed to run as a linear sequence.