I have 10 steps in build.
Often build fails at step 10 where it try to deploy rpm to artifactory.
Next time build again starts from 1 , can i configure build to start from 10step only if failed at that step.
Thanks
There is no built-in way to restart from a build step. You should rather breakup your single build configuration into multiple build configurations and setup dependency/build chains.
The other way to achieve this is to manually disable first n steps that you want to skip. In your particular scenario it is rather tedious to disable 1-9 steps and then after the build enable them again but if you need to do that for a couple on steps once in a while it might be acceptable.
Related
We need to setup a snapshot dependency in TeamCity that runs just before the dependant build starts.
Currently we have the problem that the snapshot maybe taken 30 minutes before the build starts. (The build starts later due to other factors). Ideally we want the snapshot to be taken and then the dependant build to immediately start.
Is this possible in TeamCity? Is there another way to achieve a similar thing.
Reading between the lines I'm guessing the problem here is that the dependent build isn't always run immediately when it's snapshot dependency finishes because an agent isn't always available. If that's the case then my suggestion would be to merge the two builds into a single build configuration as that will ensure that all the steps occur with no delay in between.
I have a project that needs to execute either three or four build steps depending on the branch in source control. More specifically, if I'm merging in a PR and running the build (for GitHub status notifications) I have one extra build step that is required.
It's that last build step that I need to omit if it's a non-PR branch.
Is there a way to add a build step that checks the trigger and exits the build successfully? Or a way to exclude a build step based on a branch filter?
You can check the condition and modify the step logic inside the build script. See the related ticket and an example of the script.
BTW, It is not a good practice to change the logic of the build inside build script. In this case you no longer "compare" builds in the build configuration: they start to form multiple unrelated sequences. Also the statistics of the builds will be uninformative. The recommended setup is to create several build configurations based on template.
Depending on which type of runner you are launching, but you can, in some cases, add few lines of code to get your current branch name with the property : %teamcity.build.branch%
In my case, I just add this as an extra parameter for powershell scripts and if this is a number, do something, else, do other stuff. ;)
I have two builds running in teamcity. One deploys the db, the other makes an app and then runs against the db.
So my problem is, i dont want the db build to start if the second is running.
So i need the database build not to trigger/wait until the other is finished?
You can create a snapshot dependency on build(B1) that you would like to wait on the other build(B2)
Assuming B1 needs to start only after B2 is complete
Better way is to create one build configuration with two build steps. Then set limit of running build configuration to one and you are done.
We have a lot of tests. I can break these up so that they run on seperate agents after an initial compile build happens, but is there a way I can recombine these results? Having 8 build configurations that all need to be green makes it hard to see if you've got one ubergreen build.
Is there a way in TeamCity to recombine / join builds once we've split them out? TW-9990 might help - allowing ANDs in the dependencies.
We found the answer which certainly works from TeamCity 5:
One compile build,
N test only builds that take compile.zip!** and copy to where the compile output would normally be. (via a template)
Consolidated finish:
Finish Build Trigger: Wait for a successful build in: ...
Snapshot Dependencies: Do not run new build if there is a suitable one
Only use successful builds from suitable ones
This all seems to work nicely and the whole shbang is easily copied for branches etc. Am very happy - this has worked well for us for many months now.
No idea how to do that natively. Here's my first thoughts on how I would try and tackle such a thing though:
Saving test results to files
Publishing the test result files as build artifacts
Creating a 'Merge build'
Adding artifact dependency onto the individual test projects
Writing a custom 'build' script using something like (N)Ant. This would parse the individual test results and publish the results as per the TC KB
Good luck!
Thinking outside the box you could have an overall build which doesn't really do anything (or use one of your test build configs as your 'master'), with snapshot dependencies on each of your split test builds. That way if any of them fail, the 'master' will fail because one the dependent build failed.
TW-9990 looks to be concerned with build triggering rather than dependencies.
I don't expect this to be useful in my day-to-day workflow, but when initially configuring projects for hudson there are times when I wish I could get it to try all the build steps - not just stop after the first failure.
Again, I am not advocating this for everyday use - just for configuration of the builds. (One of my projects takes about an hour or so and I'd rather not have to iterate through fixing each build step independently - I would like to fix each of them in parallel.
So, is there a way to tell hudson to continue the build steps when one fails?
The best solution right now is to modify each of your build steps to make sure they unconditionally return success, instead of an error code.
There is an open enhancement request to do exactly what you want in HUDSON-4819
This actually can be quite useful in a day to day workflow. We use Zed Builds And Bugs and it has this feature. For each build step, you simply toggle whether you want the build step to fail the build if it fails. By default it is turned on (sensible).
Where this has come in handy are things like optional steps - e.g. copying final binaries to other distribution servers. Sometimes these servers are up and sometimes not. It doesn't really matter if this particular step fails, but when it does fail, I don't want the whole build to fail.