We have a build chain setup using teamcity 2017.2.
It looks like the following
A -> B
A:
generates a version number using gitversion
has a VCS root defined
uses gitversion command line to define a version number
B:
sets its version number to the same as A using a dependency proprty
has a snapshot dependency on A with the following settings
Do not run new build if there is a suitable one
Only use successful builds from suitable ones
On failed dependency: cancel build
On failed to start/canceled dependency: make build failed to start
When I make a commit and run B it will trigger A and then B will run, teamcity will show the pending change of the commit that I just made.
However if B fails for whatever reason (and A succeeds) when I rerun B it will rerun for the same commit but the pending changes will be empty. The same also happens if I just want to rerun a previous successful build of B.
The reason this matters is that I'm using the teamcity api to pull a list of changes for a build and passing that off to my deployment tool.
I've tried enabling "Show changes for snapshot dependencies in B" but that did not seem to have an effect
Related
I have 2 repos, A and B, which both have a build configuration in TeamCity.
Changes in repo A can impact repo B. When a PR is tested on repo A (say branch R), I want to be able to start another teamcity job that tests repo B and will know about branch R. More specifically, A runs on R, B runs on Master, B has a build step that requires R as an argument for a command. In teamcity, the build config for B is a snapshot dependency for the build config of A.
This other answer showed me how to pass parameters to snapshot dependencies: Passing an environment variable (parameter) to dependency project in TeamCity
However, I can't pass the branch name like %teamcity.build.branch% because the documentation specifies:
Note that the values of the reverse.dep. parameters are pushed to the
dependency builds "as is", without reference resolution. %-references,
if any, will be resolved in the context of the build where the
parameters are pushed to.
from:
https://confluence.jetbrains.com/display/TCD9/Predefined+Build+Parameters#PredefinedBuildParameters-OverridingDependenciesProperties
You can use a finish build trigger for B and make sure the trigger can use the same branch R.
Wait for a successful build in: A
Branch filter:
+:R
I have big problem with configuring TC. It's 10.0.2 version.
I want build chain like this:
Main - Restore nuget and rebuild solution.
Code analysis - Analyse code result(do not checkout) use Main as dependency.
Publish - Publish to Azure - Use result of Main.
I set Main to:
Build numer format:%build.counter%.%build.vcs.number....%
VCS checkout dir: auto
Code analysis
Build number format:%build.counter%.%dep.<mainId>%.%build.vcs.number...%
VCS checkout dir:%dep.<mainId>.build.default.checkoutDir%
And the main dir is: 55660246e9f668c3
And Code Analysis searching in: 9ccd5731845f5aba
So it's wrong. Why?
Why?
EDIT:
What I set VCS checkout directory in "Code Analysis" build configuration to hardcoded directiory name of "Main" e.x. to 55660246e9f668c3 then it work.
So the problem is with %dep.<mainId>.build.default.checkoutDir%
You can set up a snapshot dependency, that builds from the same chain. This will ensure that the same branch, from the same root, with the same revision number (point in time) is checked out to the directory. If you use an artifact dependency, in addition to the snapshot dependency, you can achieve the same point in time consistency. So after your step 1 build runs, regardless of what new changes exist, your second build will be working with the same files your first had.
I have a TeamCity project which includes 4 configurations and the build chain needs to look something like this:
Build which can be triggered manually and executes .bat scripts that compiles a bunch of artifacts for the Deploy and TEST to pick up.
Deploy and TEST – Region 1 has an artifact dependency on the Build config.
Deploy and TEST – Region 2 has an artifact dependency on the Build config.
Since I wanted both Region1 and Region2 to run in parallel as soon as Build is successful, I added a Snapshot dependency to Deploy and TEST – Region 1 and Deploy and TEST – Region 2 on Build config
Now I need to configure the Test Status config just to report the failure/success of the previous config (Deploy and TEST configs).
How can this be achieved? Also, do I need to tweak my set up anywhere for the use case I am trying to achieve?
The setup looks correct. To get the build chain status in Test Status configuration, you need to add snapshot dependencies on Deploy and TEST – Region 1 and Deploy and TEST – Region 2 configurations. If any build from the chain fails, Test Status build will also fail with status: "Snapshot dependencies failed: ... < build configurations names >"
If you add these snapshot dependencies and run Test Status via UI, the whole build chain will be added to the queue. Also you can configure one VCS trigger in Test Status build configuration with option "Trigger on changes in snapshot dependencies". With this options enabled, the whole build chain will be triggered even if changes are detected in dependencies, not in the resulting build.
This article can be helpful.
In TeamCity* I have Build Config A and Build Config B**.
Config B depends on Config A, so when I ask B to build it checks if A needs building first.
That's usually what I want - but I often want to tell it "just execute Config B's steps without checking if A needs rebuilding".
I can't seem to work out how to do that!
The dependency is both a Snapshot Dependency and Artifact Dependency - so it must be tied to a particular instance of Config A's build - I'm ok to have to specify this.
--
[*] TeamCity v8, but as I started setting this up v9 came out, so will move to that shortly - in case that makes a difference
[**] The names have been changed - and workflow simplified - to protect the innocent
'Do not run new build if there is a suitable one' will only work if there are no pending changes and it's been recently built.
Are you avert to changing the dependency to not be a snapshot dependency and linking it to a particular artifact? You can do that under artifact dependencies by selecting from the drop down "Build with specified build number" or "Latest successful build". Of course you'd have to change it back when you were done if you wanted to switch back to snapshot dependency only.
I've configured build chain on TC.
When some build fails, dependent build shows error "Failed to start ... build on agent ..." and "Snapshot dependency failure".
Dependent build is configured to start ONLY in case of previous build succeeded. Also dependent build is configured to have the same build id as it's dependency (correspond to revision number) and thus I'm able to see last successfull commit that had been passed "the testing chain". With this in mind I don't see any advantages in "Failed to start" error message to be shown, in contrary my project page on TC is less readable. How could I configure TC not to show it?
Thanks.