I'm wondering if there is a way to force TeamCity to run a given build step even if preceding build steps fail. I want to do this to clean up after the build and terminate any started processes etc.
In Msbuild you can set the property ContinueOnError for many tasks. I usually add this using a property so it can be switched on and off:
<MSBuild Projects="my.csproj" ContinueOnError="$(ContinueOnError)"/>
Then you can set it on and off via teamcity.
So if you do this for a build step it should continue thru to the others.
I don't know if you can do it with build steps, but I've done it with two builds. The second one uses a finished build trigger pointing at the first. Finished build triggers can be configured to fire even if the first build failed.
We do our builds by constructing NAnt scripts, and then using TeamCity's NAnt runner. NAnt (well, actually NAntContrib, but still ...) has a try ... catch ... finally mechanism that does what any programmer would expect - run the catch code if the try code fails, and run the finally code no matter what happens. We use it for the same purposes as you want, plus to collect artifacts that we want the build to publish even in case of failure (like test logs).
Newer versions of TeamCity has this feature built in.
Related
I'm running a maven build in Jenkins and my builds are failing because Jenkins isn't smart enough to clean up after my build - it just tries to delete the entire workspace and the builds fails immediatly. Is there a way to NOT have jenkins fail because of this (or even try to do it), but instead let my "mvn clean" script run first? If I can do this then I can do the specialized cleanup that is required.
I suspect that you are using Workspace Cleanup Plugin. First thing to do is to check what happens if you do it as a pre-build step, not post-build.
Alternatively there is a custom step in the build that tries to wipe out the workspace. See what happens if you invoke it as the first build step, not the last. Or try using the aforementioned plugin.
If it does not help, here are other general clenup strategies you may employ:
Start another job as a post-build step that will cleanup for the upstream job.
Have a regularly scheduled (say, nightly) job that will do the cleanup. In this case you'll probably need to 'partition' your workspace by builds - i.e. create a separate subdirectory in the workspace for every build instance (keyed by BUILD_ID) so that builds do not accidentally use leftover files from previous builds.
Have a cleanup build step in your job. In this case you do not need to create extra jobs. However, as it runs before the build is over it may not be able to cleanup completely (say, it won't be able to delete the artifacts that need to be archived in a post-build step).
To summarize: Yes, you can run you script first, just make sure it does not delete things prematurely. Also examine your job configuration for where that cleanup of yours is called and set it up as a pre-build step or remove it.
I have a C++ Builder 2010 project that's being built using TeamCity. I noticed some strange errors and after reading up on them I understand that I have to set a few variables located in rsvars.bat. I would like the build script to execute the bat file to set up the environment before performing the actual build. How do I best accomplish this?
Can I just use a <exec /> command at the very beginning of the file or is there a better way?
One way would be to run wrap the build in a script that calls rsvars.bat AND build commands. That would make the variables survive during the execution of the build.
But since I use TeamCity I like it to be a real msbuild step and not msbuild wrapped in something else. I was thinking of having the buildscript setting the variables from rsvars.bat into Machine or User at the start of the build and then remove them at the end, not nice though.
I finally just went with just adding the configurations to the Build Agents environment configuration in TeamCity and keeping installation paths identical between agents.
You can create a new build step and then specify a custom build step order so a new build step will be the first one.
See Configuring Build Steps
Add them as Build Parameters -> Environment Variables (in the build configuration), straight forward and generally works. The build parameter/environment variables will be setup automatically as environment variables on the build agent running the job.
You can then make a template of the build and reuse it.
Assumes that the 'paths' are the same on all build agents, which is generally the case. If not your suggestion of doing it by build agent is the way to go.
I am using MSBuild for CI. I was looking recently to psake as an additional tool for creating scripts for daily builds as I need to do some updates to our builds which will be easier in psake. For the moment I’m not looking to replace our existing scripts as it requires a lot of work but keep the existing ones and add new using psake.
My question is - when I create a build in TFS how can I run the psake scripts after the solution is built? My understanding is that I need to add a new target after the build is executed and execute the psake/powershell. Is this the right way to do it?
Yes that is how you would do it. It is best to separate different parts of your build script so that if you want to change something, you can proceed with ease.
So, Ideally, you should have a task for compiling your solution, another for running the tests, another for packaging the source and so on ... I recently started using psake, and this is a good reference in case you want to look up something.
The right way to do this is to use TeamCity to run your psake build scripts. In your psake scripts you would create a psake Task that calls msbuild via exec { msbuild yourSolution.sln }.
When we build a Maven project without doing mvn clean, we sometimes get "voodoo errors" such as NoSuchMethodError. I believe these are caused by moving/renaming files.
I don't want to use the clean option in the CI, because it makes the build process take much longer. Is there another alternative?
You should always use clean in a CI build. CI builds must be reproducible and that requires starting from scratch!
And about the process taking longer: the whole point of using CI (one of the many) is that you can keep working while it's running, so that should not be a problem.
But what I like to do is use multiple layers of CI per project:
A first job compiles and executes some basic tests*, this build should take less than 5 minutes
if that succeeds, a second job executes all tests*, code metrics, javadocs etc
if that succeeds a third job deploys the build to a test server
(Or you can let the first job trigger both the second and the third job at once)
* You can implement the some tests / all tests functionality by configuring the maven surefire plugin differently per profile)
We have three build targets:
Continuous Integration: Builds without doing a Clean, and only run the tests identified by Clover. This runs after each commit. On success it deploys to the test server.
Nightly: Does a clean build and runs every single test. This runs every night. On success it deploys to the test server.
Release: Same as Nightly plus creates a source control label. Run manually.
The nightly build is more trustworthy in that a clean build is conducted. However, the CI build is quicker meaning feedback is faster on those occasions.
There is an underlying problem here with the build time, but this is at least a work around while you look at more permanent ways to address that.
I was hoping to know if there is a way to run a particular script, if and only if the build is successful. So if the build fails the script doesn't run.
Please and thank you.
You have several options.
Easiest: you have a free-style software project -- just create an addition build step at the end of your build. The step will not be executed if one of your previous step fails. I don't know how it behaves if your build is unstable.
Also easy: You have a Maven project: create a post build step (Steps to run after mvn build). You have the options to let these post build steps run on successful, successful + unstable, or always.
Create another job for your script and trigger it with the parametrized trigger plugin. This plugin gives you the most flexibility.
Hope that helps.