I have two build configurations: build A that has an Artifact dependency on build B. In build B I set two configuration parameters: image-name and tag, tag value being B's %build.number%. In project A I use dep.B_ID.image-name and dep.B_ID.tag. Build A is correcty triggered when B creates the artifact and both parameters are passed fine from B to A, however tag is not updated to the latest value of B's build number. In other words, I have B at build number 18, and B's tag is correctly set to 18 (printed in build log), however build A uses an earlier value of tag - 16. If I trigger build A manually, it picks up the latest tag number from B just fine. This is happening in two different projects. TeamCity version 2017.2.2 (build 50909). Any pointers appreciated.
Update
Currently every time build A is triggered by build B, it picks up previous artifact from build B. In other words, build B is at id 23, so artifact 23 should be used by build A. However build A is using artifact 22 instead. This is consistent across projects.
Upgraded to TeamCity Enterprise 2019.1.4 (build 66526) and the issue went away.
Related
This question was migrated from Super User because it can be answered on Stack Overflow.
Migrated last month.
Context:
We're running the free version of Teamcity to manage our projects. Some of those projects have dependencies between each others.
The problem
Some projects have chained Snapshot Dependencies, and those dependencies are always being built instead of the latest artifacts from those dependencies being used.
Example: A depends on B, B depends on C. Push A triggers a build of C, followed by a build of B and finally a build of A.
Ideally: A would be built based on the latest built versions of B and C
Where I think the problem lies (but I might be wrong)
Each of our projects has a number of Snapshot dependencies, and each snapshot dependency is configured with the following parameters turned on:
[x] Do not run new build if there is a suitable one
[x] Only use successful builds from suitable ones
For the first option, the documentation says:
If this option is set, TeamCity will not run a new dependency build, if another dependency build in progress or completed with the appropriate source revision already exists. See also Suitable builds: (https://www.jetbrains.com/help/teamcity/2022.10/snapshot-dependencies.html#Suitable+Builds).
If we look in the Suitable Builds doc, it shows a list of requirements for a build to be considered suitable. The one I think is relevant is here:
It must not have any custom settings, including those defined via reverse.dep. (related feature request: TW-23700: (http://youtrack.jetbrains.com/issue/TW-23700)).
However, we currently have reverse.dep.*.env.SOME_PARAMETER as a Configuration Parameter in every single one of our builds (it's inherited through a template).
Based on that, it seems to me that the "Do not run new build if there is a suitable one" option is doing nothing, and therefore that's why all our dependencies are built every time (or am I wrong?)
We also have, in every one of our builds, an environment variable called env.SOME_PARAMETER which has the same value as the reverse.dep configuration parameter.
My question
Is there a way to avoid using reverse.dep in my situation so that the Do not run new build if there is a suitable one option works? Perhaps by using the environment variable instead?
I asked the senior developer at the company I work in, and they said that in theory it should work, but in practice it doesn't, but he seems recitent to explain further. I'm just a beginner in Teamcity, so detailed explanations are welcome
First things first: what is a Snapshot Dependency in a nutshell?
A Snapshot Dependency in a nutshell is a dependency between two build configurations which are linked by shared VCS Roots. VCS Roots are sort of like time lines in a book: they represent a chain of events (e.g. git commit history) and let you build from a givent point in time (e.g. commit).
Now, TeamCity excels at doing what it is intended to do: Continuous Integration and Deployment. It does so by being tied up closely to VCS Roots and effectively changes in these (optionally narrowed down scopes of the) VCS roots. A Snapshot Dependency is a dependency which links together the dependency based on VCS Roots and their changes.
An example
Build A has two VCS Roots, Foo and Bar. Foo and Bar are, say, different Git repositories which Build A needs to fetch before it is able to build the "A" artifact. Build B only needs Foo, and thus only has Foo attached as a VCS Root. Build A has a Snapshot Dependency on Build B, which we configure like yours: "Do not run new build if there is a suitable one" and "Only use successful builds from suitable ones".
So far so good. Now let's push a new commit to the "Foo" repository. TeamCity notices this and potentially triggers a new build of Build A, because the latest build of A is at that point outdated (it did not have our latest Foo commit included). The Snapshot Dependency of B in A links these two build configurations together so that - with our above configuration of the Dep. - we can require a build of B which includes the same revision of Foo, that build A was kicked off with (e.g. the latest commit). Because this does not (yet) exist, a build of B is started and put above build A in the queue.
Simply put: the VCS Root is a timeline, the Snapshot Dependency is a link between two build configurations based on the timeline(s) they have in common, and the configuration of the dependency dictates what should happen when a dependency is needed (e.g. "Do not run new build if there is a suitable one").
If we had manually started a build B with the latest Foo revision included, this would have been a suitable candidate for reuse, and TeamCity would simply remove the queued B build once it discovered that a build of B already exists, which shares the same changes that build A is started with (the latest push to Foo).
If you want just the latest artifacts of B and C...
...use Artifact Dependencies and only these. Removing the Snapshot Dependency of the build removes your need of having the dependency build every time Build A is triggered by a new change in its VCS Root. It however also means that there is no timeline linkage between the two builds and that you yourself need to ensure or be sure that the artifacts produced by B and C are not tightly linked to A. E.g. Build C could produce a driver as an artifact, B could produce a user manual of the driver and build A could just be using the driver, only expecting that it is in a working condition (but otherwise does not depend on changes in it).
Your question about reverse.dep.*...
I've not heard about this causing trouble before. I would however expect that a Snapshot Dependency (and not just an artifact dependency) is required by TeamCity for you to be allowed to use it.
Question is: do you need it? It sounds like you've got the value elsewhere already, and honestly fetching values from previous builds is likely going to cause you trouble in the long run, especially if you don't have a specifically good reason to do so.
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'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.
Our current SDLC goes something like this:
Develop code & unit tests
Release to QA for system testing
Repeat steps 1 & 2 as required until QA is passed
Promote to UAT
Repeat steps 1 to 5 as required until UAT is passed
Deploy to production
We are using the maven-release-plugin to manage the releases, but want to maintain the same build number throughout the cycle. Currently each time we build, the artifact release version increases. e.g. 1.2.3 released to QA, fix errors and rebuild becomes 1.2.4, etc.
We have looked at using the release:stage goal, however the first use creates a tag in SCM, and each subsequent use of release:stage builds from this SCM tag, and does not include any code added after this tag is created. We've tried using release:rollback after release:stage to remove the scm tag, but this does not work.
Is there a way to perform this type of release cycle?
Thanks.
For our project, we uses snapshot for CI, beta for the step 1-5 cycle.
We've just started to use TeamCity as a continuous integration server. There's a problem we're trying to solve now:
We have a 'release' configuration, it has build versions set like this: 1.0.0.{0}
We also have a 'nightly build' configuration, which build number is: 1.0.0.0.{build.vcs.number.1}
So the first 2 digits are OK, Major+Minor versions. Third one is supposed to be set up manually as well according to our process (rarely though).
But as you can see, the last one increases with every 'release'.
The question is - how do I make TC copy the current 4th digit (or all of them) of 'release' to that of 'nightly build'?
One way to do it in 4.5 is to
Make nightly have a snap shot dependency on release.
find the internal build id of release.
use a build number format in nightly that looks like
%dep.releaseid.system.build.number%.{build.vcs.number.1}
where releaseid is the id you found in step 2. This will replace the whole %...% thing with the build number from release.
The TeamCity 4.5 Docs for dependency properties explains this and shows you how to find the internal id.
If you can know it in your build script, you can send it to team city during the build. Here are the instructions. I can think of a couple of strategies for getting the build number from the release build, none of them elegant. The most obvious would be to publish an artifact from the release build that is basically a text file with the build number in it, and retrieve that from your build script.