I have the following set-up in TeamCity 7.1.3:
Project A
Build & Deploy A
Test A (Quick)
Test A (Slow)
Test A (Very Slow)
Project B
Build & Deploy B
Test B (Quick)
Test B (Slow)
All of the tests for A depend on 'Build & Deploy A' and all of the tests for B depend on 'Build & Deploy B'. The dependencies are all snapshot dependencies with the following settings:
Do not run new build if there is a suitable one
Only use successful builds from suitable ones
Run build on the same agent
All of the tests have VCS triggers. The slow tests only run when particular folders in source control are changed. When a commit is made to project A, the following projects are added to the build queue:
Build & Deploy A
Test A (Quick)
Test A (Slow)
Test A (Very Slow)
Pre-commit builds run with higher priority in the build queue. As such, if while 'Build & Deploy A' is running a pre-commit check is made to project B, the build queue then looks like:
Build & Deploy B
Test B (Quick)
Test B (Slow)
Test A (Quick)
Test A (Slow)
Test A (Very Slow)
The problem with this set-up is that it will mean that the tests for A are run after project B has been deployed. This is an issue as the deployment of project B overwrites some of the files required by project A. The files which are being overwritten by the personal build are deployed files which are not in the checkout folder which is why they are not rolled back. Is there any way to enforce that the build chain for the tests isn't interrupted?
If I remove the 'Do not run new build if there is a suitable one' setting from the dependency, each of the tests will require a full build and deploy. The slower tests can't depend on other tests to make a linear chain as sometimes 'Test A (Very Slow)' is run, but 'Test A (Slow)' isn't.
Unfortunately it isn't currently possible to split the build and deploy to create artefacts.
Is there any way to efficiently set this up in TeamCity?
Here's what I'm gathering:
A and B should be considered mutually exclusive.
A should always have a lower build priority than B, but
Once started, A should not be interrupted.
There may be a way to fight TeamCity on this; I don't know. If you're open to changing your process a bit, one of these might work for you :
Clone your environment such that A and B can be deployed to different targets. This would allow them run completely independently of one another. Use multiple build agents (at least one each for A and B) to allow the faster, higher priority B to execute at the same time as the slower, lower priority A. (This, I think, would be a significant perk.)
Make your process more atomic. Merge the various build/deploy/test pieces into a single configuration, thus ensuring that pending portions of the A build chain can't be displaced by B.
I solved the problem by making both 'build & deploy' build configurations write a text file to the deployment folder containing the build type and build number. All tests compare the values in the text file to the current builds snapshot dependencies. If they values are different, re-trigger the build (forcing dependencies to be rebuilt) and then cancel the current build.
Cancel build by calling:
http://teamcity.jetbrains.com/guestAuth/ajax.html?comment=<CommentMessage>&submit=Stop&buildId=<BuildId>&kill
How to trigger build with dependencies set to rebuild:
Is it possible to force a TeamCity build to rebuild dependencies when triggered over HTTP?
This means that when a test is running out of step, the deployment will be re-triggered and then the tests will run.
Related
I have a bulid configuration A for merging feature branches in my project, which runs configuration B for several different modes (dev and prod). B compiles the project and runs tests. The mode is passed via a bulid parameter.
I've set it up this way:
A depends on B-dev and B-prod
B-dev depends on B, passing a dev mode parameter, and has no steps
B-prod depends on B, passing a prod mode parameter, and has no steps
I want to run B two times in the same chain, but looks like Teamcity doesn't allow that. Is there any way other than duplicating the B configuration?
When configuring your snapshot dependency from B-* to B, uncheck the flag "Do not run new build if there is a suitable one":
According to the docs:
If the option is enabled, TeamCity will not run a dependency build, if another running or finished dependency build with the appropriate sources revision exists.
I'm exploring Jenkins staging functionality and I want to devise a fast and lean setup.
Basically, Jenkins promotes the use of stages to partition in the build process and provide nice visual feedback about the progress of the build.
So the Jenkinsfile goes something like
stage("Build")
bat("mvn compile")
stage("Test")
bat("mvn test")
stage("Deploy")
bat("mvn deploy")
This works well, but feels wrong, because deploy and test will both do activities from previous phases again.
As a result, in this setup I am building three times (although skipping compilation due to no changes) and testing two times (in the test and the deploy runs).
When I google around I can find various switches and one of them works for skipping unit tests, but the compilation and dependency resolution steps happen regardless of what I do.
Do I need to choose between speed and stages in this case or can I have both?
I mean:
stage("Resolve dependencies, build, test and deploy")
bat("mvn deploy")
is by far the fastest approach, but it doesn't produce a nice progress table in Jenkins.
In order to bring incremental builds in Maven phases as Gradle does, you can use takari-lifecycle maven plugin.
So, once the plugin is apply you will get all the benefits. In your example, Test stage which will perform mvn test will avoid compilation because it was compiled in the previous stage and Deploy stage will avoid compilation from your main source code and test source code but tests will be executed again so I suggest to add -DskipTests.
I'm fairly new to TeamCity (but not to CI systems) and I've been trying to figure out how to work this configuration out:
I have latest TeamCity Professional Version 9.1.3 (3 build agents, 20 configs) installed
Here's my TeamCity Project layout:
Project A
-- Build Product X (WIN)
-- Build Product Y (WIN)
-- Build Product Z (Linux)
I have dedicated 3 agents to build the above build configurations accordingly - 2 on Windows and 1 agent on Linux
WIN products are built using a mix of batch, powershell and msbuild scripts
Linux product is built using shell script
Triggering these 3 builds (under Project A), manually, works just fine. However, this is not feasible as we have many feature branches and all of them would have similar build configurations - 3 clicks for each build + setting Build Parameters on each Build configuration is expensive.
So, Here are my questions:
Is there a way to trigger the entire Project to build with a Single click? doing so, should run these builds in parallel
If 1 is possible, then how do I set the same build number (build params) across these 3 build configurations?
Is it possible to set up a VCS trigger that would poll for changes on any of the repos that build these and trigger the entire project (provided 1 is possible)
Please note I tried configuring both snapshot and artifact dependencies to make this work, but creating dependencies only pauses the other build configurations to wait until the dependent project is complete but that's not feasible for us - they need to run in parallel. (our builds take approx 45mins to complete) - Yes, we have a huge product to package.
I'll be grateful for any pointers in the right direction
Thanks
Yes, one-click triggering of parallel runs is achievable: create a 4th (or 0th) build configuration that does nothing (no build steps). Let's call this config "Zero". Your three build configs will each have a "Finished build" trigger on Zero (trigger when Zero finishes) as well as a snapshot dependency on Zero.
The best bit: you only need to define the common/shared parameters in Zero and the other three configs can reuse these. For example, if you define %foo% in Zero, the other three can all use %dep.MyProject_Zero.foo%. This also means you can get at Zero's build number: %dep.MyProject_Zero.build.number%. In each of your three build configs, switch to the "General Settings" and set your "Build number format" to the above.
For VCS triggering, just set Zero to span all the three VCS areas. You're suggesting they are each in a different repo... I have no experience with that but assume that Zero can span all three repos.
Last, if you use feature branches, and your VCS is git, mercurial, or Perforce Streams, make sure you've read about TeamCity feature branches support; it can save you a lot of time!
I have some build configurations added into TeamCity. I want to identify builds which are triggered via code change only. Take for example,
I have build configurations A, B and C.
C has snapshot dependency on A and B.
When I make changes to C TeamCity also triggers build configurations A and B.
Here, all three builds are triggered. I want to identify the builds which are triggered due to code change (in this case only C) and get the artifacts from those builds only.
I have several build configurations in my TeamCity and many are dependent on each other. Is there a way to achieve this? May be some file or something gets generated which will tell the build configurations triggered due to code change? I just need some pointers to identify the builds, I would implement it as it suits my project.
I've started using TeamCity personal builds, via the new Git remote run feature in TeamCity 6.5. Doing a single build works fine; I have a project that compiles from source, and I gave it a Branch Remote Run trigger.
However, it looks like TeamCity only triggers the one project that has the Branch Remote Run trigger applied. I have several unit test projects, set up in a chain with Finish Build triggers, and none of these get run. Furthermore, if I try to start a custom build of one of these unit test projects, I can't use the artifacts from my personal build: I can only pick artifacts from one of the 'official' builds.
Can I get TeamCity personal builds to work with build chains?
With the setup that you have (snapshot dependencies and finish build triggers), you can achieve build chaining by submitted your personal changes to the builds you are looking to trigger. For example, if you have projects A and B where B depends on A - run the remote build against project B and A will be triggered first and B will be added to the queue. Both of these builds will have your personal changes.
If you are using the TeamCity Visual Studio plugin you can select which builds you want to send your changes to and you just need to tick the box for B instead of A.
The finished build trigger won't be fired, but the build chaining means that A must be built first.
More info - http://confluence.jetbrains.net/display/TCD7/Build+Chain
(You have tagged TeamCity 6.5, but 7 has now been released so I have included the documentation for the newer version)
I suppose you should setup your chain not with Finish Build trigger, but with "Snapshot dependencies" feature of TeamCity. And, setup artifacts dependency basing on the snapshots.
Please read about snapshot dependencies in TeamCity here.