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.
Related
If I understand correctly I can make a build step conditional using this plugin: https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
First does this plugin work the Post-Build steps?
Second is there a way to make Post-Build steps conditional without a plugin?
The scenario I have is I am supporting both WebDriver and Selenium IDE tests with one universal Jenkins Job setup. If they have checked in either type of test it runs them. I then want it to conditionally look if any results files show up and if so then do the publish results Post-Build step, otherwise skip that step.
Currently if no results show up it simply marks the build as a failure since no test results were found.
Any suggestions would help!
You can make any Build step execute as Post-build step.
Install Flexible Publish plugin
Install Any Build Step plugin
Under Configure System, look for "Flexible publish", and choose Any build step from drop-down.
The configure Job.
In your Job configuration, add Post-build action called "Flexible Publish".
Select condition.
Select action.
It is posssible but it is a bit messy and can not be done with ui only.
Create the the conditional build step in the build block and save the konfiguration. Edit the xml file and move the whole conditional build step it to the post build block. Reload the jenkins configuration and it works like intended.
When I run my build script from TeamCity I can output ##teamcity[buildNumber '<new build number>'] and TeamCity will update the build number accordingly.
How can I do this in Bamboo?
You can't - at least not in a supported way.
Even ignoring the build script portion of your question, Bamboo simply doesn't support editing of build numbers like TeamCity does.
Here's the feature request
If you really want to edit the build number, you may be able to do it manually (at your own risk!) with a few SQL queries. This post from Atlassian's forums should help you get started.
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.
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.