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.
Related
I am struggling a bit with the concept of azure pipelines and am looking for hints on how to solve the issue:
We have one Build definition that produces a binary artifact "Generator" in indeterminate intervals.
We have another build definition that should run every night, pull some source code from a repo, obtain the "Generator" artifact from the other build definition, execute it on the source and produce a new artifact.
The problem I have is, how can I get the latest build from the other build definition?
Here is a screenshot of my problem:
While I can select the proper build definition, the Build has to be an actual build. I cannot add "latest" here (tried and failed) but I don't really want to pin the build number.
Imagine the "Generator" to be something that gets updated once in a while and adds new features etc. The separate build definition at hand, which is not related to the build definition producing the "Generator" just wants to use the "latest" generator and to generate something from its own repository that can be published as an artifact afterwards.
I am pretty sure I am missing something and would be glad to get some hints. (Setting Current build instead of Specific build) actually does not allow me to select the project and build definition that is different from the current one.
Get latest artifact from Build Defintion X and use it to produce a new artifact
It seems the task Download Build Artifacts you are using is not the latest version, like 0.131.1. When I add this task (My version is 0.148.1), there is an option Build version to download that I could select the latest version:
So, try to remove it and add it again, check if you have that option.
Check this ticket for some more detail about this issue.
Besides, if you could not get the latest version, you can try to use the Fetch Build Artifacts task instead.
Ticket here.
Hope this helps.
I am currently implementing (I do not know if implementing is the appropriate word, but anyway) a semantic versioning in TeamCity. I have project level system parameters in which I store version number parts: system.major, system.minor, and system.patch. I have two build configurations:
First, we call it beta, is using the major, minor, and patch as-is and appends its build counter value to the version (i.e 1.0.0.X where X is beta's build count).
Second, we call it release, is using the major, and minor (but not patch) as-is and appends its build counter value as patch number (i.e 1.0.Y where Y is release's build count).
We want our versions to increment like following:
A beta build is run: 1.0.0.1
Another beta build: 1.0.0.2
A release build is run: 1.0.1.0
Yet another beta build: 1.0.1.3
The problem is, we want to use the release build's counter as patch number in beta build as well, without any human intervention. So far, I have read about people using assembly info or external VCS-tracked file to store the current version in last build step and parse the file in the first build step of every build configuration. This approach, though appears to be the standard way, is not welcomed by the project's manager, so I want to avoid using assembly info or another VCS-tracked file to store the version info. I have tried to use a powershell script build step in release configuration to set the parameter patch using:
Write-Host "##teamcity[setParameter name='system.patch' value='%build.counter%']"
yet, using teamcity[setParameter...] appears to take effect inside the running build and only on consecutive build steps. What I want is to set the system parameters in one build (release) and later, use their value in another build configuration (beta).
Is there any straight-forward way that I fail to see? If you have similar experience, can you point me to the right direction?
I am accomplishing something similar by doing an API call in a build step through powershell. Could this work for you? Do a GET request to find the current release build counter and then update the appropriate parameter with a PUT request.
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 would like to use some build parameters from Project 1 in Project 2. I know that I can make Project 1 a dependency of Project 2 and then access its build parameters as described in Dependencies Properties, but I do not want Project 1 to be built in response to a build of Project 2. For example, suppose I want Project 2 to be built nightly, while I only want Project 1 built monthly.
Is there any way Project 2 can access Project 1's build parameters under these conditions?
I would use a build configuration template that is shared between the two projects.
This means you can share properties between the projects, but also override certain ones in each individual project.
We use this for hourly builds that are not tagged and nightly ones that are tagged.
Then use a different build trigger to set one off nightly and the other monthly.
EDIT
I'll just expand slightly as a result of your comment.
In TeamCity we have 2 build configuration for the same project. One that builds on every check-in to give developers quick feedback on their contribution (build within 15 minutes). It does the following:
Builds the project in Debug
Runs all unit tests
Checks results of build into Subversion
The other configuration runs every night at midnight; it build everything and as a result takes a long time (around 45 minutes). It does the following:
Build the project in Debug and Release
Runs all unit tests
Builds Sandcastle documentaion
Checks results of build into Subversion
Grabs the Sandcastle output at an artefact so developers can easily download it.
As you pointed out this isn't as straightforward as one would like; however you can use the following to achieve it:
We use the Autoincrementer to share build numbers between the two configurations (they both increment the same build number when built).
We have a property on template that defines what artefacts to collect and is referenced from the artefacts field. The property is overridden on the second build config to define the sandcastle output to grab.
Sharing VCS Roots is mentioned on the documentation. Both our builds get the source from the same place, and tag the results to the same place. One VCS is most definitely all we need.
Bit of a long edit but I think it goes exactly on the lines of what you're trying to achieve. I appreciate I should have included this in the original answer.
HTH
Dependency is different from Build Triggering in TeamCity. If you make one project dependent on another ( artifact dependency ), it does not mean that the the latter will trigger the former.
Even when one project has been defined as dependent on another ( and also, even if not ) you have to specify explicitly the build trigger ( in this case a Finish build trigger ) for the dependent project to be triggered.
My TeamCity's nightly build produces more than 130Mb java doc as Build Configuration artifact.
I have to share these artifact for other teams(developers), but javadoc every time has another one URL(I know that it's possible to get it like .lastFinished), and get's new place on Build Machine.
Is it possible on each build replace old artifact with new one because I don't need need previous versions? And have independent from build version URL for accessing.
You can configure TeamCity to delete artifacts after the n-th subsequent build - set this to 1, and it won't keep much for you. Look under Administration at Build History Clean-up Policy.
And the independent from build version URL should then probably be the .lastFinished one you mention.