I have multiple VCS roots set up (Core, AuthN, Other). Due to out of control cross-cutting code, when we build Other, we need to download Core and AuthN in order to build a testing database for integration tests. Where I'm having issues is that we'll have up to 3 different branches of each active at any time: Current, Patch, Hotfix. When Other builds, the correct branch of the other 2 needs to come down as well, (e.g. if Other's Hotfix branch builds, it needs to pull Core and AuthN's Hotfix branch). Since these specific build numbers change on a regular basis, I'm uncertain how to get Other to identify which branch it needs.
I have Other set up with 3 VCS roots (one for Other, Core and AuthN), each with their own branchName parameter as the default branch. I also have a series of parameters created that identify what the current patch and hotfix version is for the next releases. I then created a PS script, that uses these values, plus the current branch name (Other's version), to set Core and AuthN branch names, but that build step doesn't run until after VCS downloads have completed. How can I get the correct version of Core and AuthN for a given version of Other
If the branches in the different repositories are with the same name, you can probably use TeamCity feature branches and snapshot dependencies between the different build configurations.
So if the build chain triggers on a change in a particular branch in one repository then TeamCity will do its best to trigger the builds for the corresponding branches in the rest of the chain.
See the screenshot:
If there's a change in 'hotfix' branch of Step1 build configuration (#8), then the corresponding branch is built in Step2. However, if there was a change in the 'alternative' branch that only exists in Step2, then Step1 will be built from default branch which is 'master' in this example (#10).
Related
I got a project that is stored in svn and let's say mirrored in git.
Long story short: svn has bad connection, so we don’t branch in svn, use git through "git svn" to synchronize repositories and creating feature branches in git.
Earlier we got two build projects in TeamCity to handle that, but now I added few deploy projects that depends on a build artifacts, so I don’t want to duplicate them too.
In TeamCity, during the build I would like to prompt what VCS Root to use.
So, I added two VCS Roots, setup connections, setup checkout rules and set "VCS checkout mode" to "Do not checkout files automatically".
As I understand now I need to create a build step to manually checkout files from the chosen repository.
Is there something inside TeamCity that can allow me to reuse VCS Roots (and checkout rules) I already setup?
I mean is there any command that can checkout just by providing “VCS root ID”, or should I redefine all checkout rules completely on my own?
One of the approaches would be to utilize conditional build steps.
Set up two different build steps that perform manual checkout from each repository and execute them based on a parameter's value. You can then configure the parameter to have the 'Select' type. Optionally, you can set its 'Display' value to 'Prompt' so that TeamCity will always ask you to select one of the pre-defined values.
Note that checkout rules won't directly affect manual checkout. They are only applied when auto-checkout mode is used. They will still affect revisions that are attached to builds in the UI, though.
Another approach is to set up a simple build chain by adding another build configuration in front of your main build config. The first build in the chain will perform a REST API call that updates the checkout rules on both VCS roots that are attached to the second config. You can set the -:. rule to a VCS Root that you don't want to be checked out. To make things simpler, you can store checkout rules in parameters, and assign these parameters to checkout rules of your VCS roots. The benefit of this approach is that you'll be able to use auto-checkout in your main build configuration. Again, you can utilize conditional build steps here to define which REST API call should be executed.
We're using teamcity with github enterprise. And we have it set to run on merge requests as well as commits. However, git keeps sending teamcity commit messages for merges that have 0 file changes, which triggers a build.
For example, this will trigger a build:
I've found the documentation here for creating a trigger filter
But I don't see a way to create a filter on the number of updated files.
I think this is what's causing the builds
Triggering a Build on Branch Merge
The VCS trigger is fully aware of branches and will trigger a build once a check-in is detected in a branch.
When changes are merged / fast-forwarded from one branch to another, strictly speaking there are no actual changes in the code. By default, the VCS trigger behaves in the following way:
- When merging/fast forwarding of two non-default branches: the changes
in a build are calculated with regard to previous builds in the same
branch, so if there is a build on same commit in a different branch,
the trigger will start a build in another branch pointing to the same
commit.
- If the default branch is one of the branches in the
merging/fast-forwarding, the changes are always calculated against
the default branch, if there is a build on same revision in the
default branch, TeamCity will not run a new build on the same
revision.
It's worth noting, that builds on branches that haven't been updated will be triggered by a merge in another branch.
You probably use checkout rules. Otherwise, running a build on a merge commit with 0 files seems an appropriate action: the commit does change the content of the checkout directory and should trigger a build.
If you limit what you checkout via TeamCity checkout rules, TeamCity only displays the merge commit with 0 files if it actually changes the content of the checked out directories (by merging files in the directory), or the commit graph is not fully known to TeamCity, and it potentially can affect the checkout.
If you are not running the latest TeamCity release (10.0.5 as of now), it makes sense to update. If you still get merge commits displayed which are not affecting the checked out files and are not merging commits created before the VCS was configured in TeamCity, it makes sense to report the details to TeamCity support.
I have several projects that produce NuGet packages that I publish to an internal server. We're using semantic versioning, and using tags in our Git repository to control the version numbers.
I'm tagging like this:
git tag -a v1.0.0 -m "tagged"
And, during the TeamCity build, I run git describe --long, which produces an output like this:
v1.0.0-0-ge9c047d
The fourth number in the output is the number of commits after the tag. The 0 here means that no commits have been made since the tag. I use these first four numbers as the version number (and, incidentally, the entire string as the AssemblyInformationalVersion).
I have TeamCity package and publish a NuGet package, but here's where it gets sticky. I only want to publish tags, never commits after tags (because the version number in that case would be wrong, possibly VERY wrong).
I've tried setting the "branch specification" in the VCS root to "+:refs/tags/*", which causes all the tags to be built, but TeamCity also insists on building the "default branch" as well. If I set the "default branch" to something that doesn't exist, I get an error.
I've thought about ending the build early if a particular build isn't a tag, but I can't figure out how to do that without FAILING the build, which isn't what I want.
How do I cause one or more build steps to only run for new tags, and not regular commits?
If you are using TeamCity 8.x, there is now support for VCS branch triggers, which would allow you to not run builds from the default branch.
Try this:
Leave the Branch Specification in the VCS Root as "+:refs/tags/*"
Change the VCS build trigger rules to:
+:*
-:<default>
This will filter out the default branch from the trigger and you won't need to cancel the build.
I am using teamcity 8.0 with github.
I have a continuous deployment build configuration set up to look at our master branch and when changes occur they are built and deployed.
When code is ready for deployment it is merged in from another branch into master, so master is always a snapshot of the last deployed code. ongoing development happens on other branches.
The problem we have is that when we deploy there is usually at least 20 commits and often many more from a mix of developers. Team city builds and deploys each commit separately which takes an age and leaves our live system unusable while this is occurring.
Is there a way to configure team city to just build the most recent code when it detects a change instead of every individual commit
Review your VCS trigger settings. "Per-checkin Triggering" should be turned off.
Also, check if you are using GitHub Service hook for "TeamCity" - it may also produce number of builds.
I am working with Team City for .net and use it for continuous integration - works well. I have it running off my main branch.
I now have a release branch - how I can I configure to set up a release branch in team city. What is the best way to do this?
What I've done before is to copy the build configuration of my trunk build and then just create a new VCS root pointing at the other branch and use that in the new configuration.
Your can track several branches using Branch Specification field of VCS root. Specify wildcard for you branches like
+:refs/heads/release_* (for release branches) or
+:refs/heads/* (for all branches)
More details in docs.
Some notes:
Run build button runs it for default branch. Click ellipsis -> Changes tab to select specific branch.
Now you cannot use artifact dependencies for specific branch. Such dependencies will always use the default branch.
Regarding issues with artifact dependencies, it's not easy to create deployment configurations from branch specific artifacts. In this case I'd go using separate configurations for each branch. Otherwise you should rely on API and/or some artifact path name parsing logic.
If you don't need per branch deployments, it's completely ok to just use branch specs approach.