My TeamCity project has builds created in below fashion:
Build-1
Build-2
Build-3
Build-4
Build-5
Build-6
Build-7
I have currently chained the execution of all the builds one-by-one serially in this project by setting the "Finish Build Trigger" in each of the builds from #2 through #7.
What I'd like to achieve is, loop through builds #3 to #6 with the loop parameter being files from a certain directory (one file at a time in the loop) from the VCS Root attached to build #3. Is this feasible? If yes, I would like know, how.
I think for such a dynamic scenario you need to use TeamCity REST API.
I'd wrap builds #3 to #6 to separate build config called let's say Loop3To6.
Loop3To6 config has a build step which has a script which loops through files from certain directory and for each file you trigger builds #3, #4, #5, #6 using Trigger Build
Then Loop3To6 set Finish Build Trigger to Build #2 and Build #7 set Finish Build Trigger to Loop3To6.
Related
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. ;)
Without Teamcity I would put everything into one big .fsx script and just "fire and forget" it. It would be OK to have a single script for the build, doing all the work.
But when we put .fsx script into Teamcity, everything changed. Teamcity has nice build log and build steps features, but putting all logic into the same script and build step resulted in HUGE build log.
We have build and tests in a single .fsx script, and I was going to place distributive building into it either. But now I don't think that this is a great idea. Perhaps it would be better to split this build script into several build scripts and run them in several build steps?
But with several scripts it's not too convenient to run build locally, without Teamcity if we need to. Or we can have several small build scripts for every task ans one build script for the local build calling all these small scripts.
What is the best solution for this?
This is my personal opinion and not a "best solution": I would not use multiple build steps or build pipelines in Teamcity since this will lead to vendor lock in.
That said if you still want to use build pipelines then use a single build file and make heavy use of FAKE's build targets and conditional dependencies.
if isLocalBuild then
A
==> B
==> C
So you can still run it locally like before.
In TeamCity define a build pipeline which calls only one target in every build step (using FAKE.exe target=A).
Well, I suppose I've done something similar to #forki23 suggestion. I've put everything into a single .fsx, defined several target's chains not related to each other, like this:
Clean ==> Build
BuildTests ==> RunTests
SignExes ==> PackDistr
and on each build step I call one "leaf" target, i.e.
Step1: fake build.fsx target=Build
Step2: fake build.fsx target=RunTests
Step3: fale build.fsx target=PackDistr
Locally, I created several .bat files for building locally, and I've defined target's call order in these .bat files. But I suppose it would really be better to use the isLocalBuild value as #forki23 suggested. This would make build logic more encapsulated into single .fsx script and that's great!
I’d like to be able to specify that one build project should pause while another specified project is running.
In my case, there is a project #1 that builds and deploys compiled code to our servers, and a project #2 that performs Selenium tests on that deployed code. The tests can take several minutes, and I’d like to make sure that the build-and-deploy doesn’t happen in the middle of testing.
So, I’d like to pause #1 (build) while #2 (test) is running.
Dependencies or Triggers do not offer this option, as far as I can tell. Can this be configured?
There is a request on TeamCity issue tracker TW-3798. You are welcome to vote and watch.
This functionality is currently being developed. For now you can use one of the features provided by GroovyPlugin called StartBuildPrecondition. To ensure that only one build is executed add the same write lock to both of the builds
The way we do this is by restricting them to one build agent. They you are insured that only one runs at a time.
We are using Hudson for our builds and deploys. Currently we have four main jobs: BUILD, DEPLOY-DEV, DEPLOY-TEST, and DEPLOY-PROD.
The BUILD job is parameterized, so we can assign new version numbers and augment them with the BUILD_NUMBER managed by Hudson. This works very well. We also have a "nightlybuild" parameter that defaults to false. Our intention is to only set this via another Hudson job.
We are trying to have an automated NIGHTLY-BUILD job that first calls our BUILD job with the "nightlybuild" parameter set and once that is successful, call the DEPLOY-DEV job. We also want to call out to a SONAR job to analyze the code, but for this question, the 2-step solution is sufficient.
For the NIGHTLY-BUILD job, the only way to call a parameterized job that I can figure out is the post-build action of "Trigger parameterized build on other projects". I can't trigger off of the BUILD job directly because the "nightlybuild" default is false and I also don't want to trigger off any manula builds. I also have a NIGHTLY-DEPLOY that has a build trigger of "Build after other projects are built" on NIGHTLY-BUILD. Since these are both ultimately post build actions they trigger at the same time instead of consecutively.
Started by user anonymous
Triggering a new build of BUILD #49
Triggering a new build of NIGHTLY-DEPLOY #3
Triggering a new build of NIGHTTY-SONAR #3
[DEBUG] Skipping watched dependency update; build not configured with trigger: NIGHTLY-BUILD #5
Finished: SUCCESS
When I start the build, it completes in a few seconds and starts the BUILD and DEPLOY concurrently, so as a new version is building, the old version is deploying. Not what I want.
I looked at and downloaded the "Build Pipeline Plugin", but it looks like it just relies on the same post build actions for the automatic transitions and adds new functionality for manual transitions.
Does anyone have any suggestions on how to resolve this issue?
Use Parameterized Trigger plugin as a build step, not post-build step. Then it has an option to wait for the downstream build to complete.
Note: this works with Jenkins, I can't guarantee that this option exists in the Hudson version of the plugin.
I have created many build configurations in Hudson for a single solution (eg. Release, Debug, Test)
When I commit something wrong, I receive 1 build failed e-mail for every build configuration.
I would like to receive a single e-mail.
I think if I could to make one build dependent on the success or failure of another, I could receive less e-mails.
How to do that?
BTW: I use MsBuild, Subversion and NAnt
It sounds like you have multiple jobs (build configurations) for the same set of source code that are configured to always build. You could, as someone else suggested, use build triggers to chain these jobs together. However, if all the jobs run on each commit, I suggest combining the jobs into a single job with multiple steps. That way when one step fails, the entire build will fail, no unnecessary Hudson cycles will be spent, and you will not receive redundant emails. To add steps to a build, click "Add build step" and select "Invoke Ant" (or whatever other action you want it to take).
You can use the build trigger "build after other projects are build" to put projects up- or downstream from one another. Then you typically let the lighter builds go first (like simple compile).