The TC docs basically imply that you can choose a branch in the Custom Build Dialog from branches that appear in your snapshot-dependencies, but I cannot get this to work.
In fact the list of branches I see neither appears to be from my build configuration, nor the snapshot-dependency. The docs also imply that branch tags will show up in the UI if you have branches in your snapshot-dependency, but they don't unless I attach the same VCS root.
In "Triggering a Custom Build" it says:
From 8.x docs:
If you have branches in your build configuration (or in snapshot
dependencies of this build configuration), you can choose a branch to
be used for the custom build in this dialog.
From 9.x docs:
The Build branch drop-down, available if you have branches in your
build configuration (or in snapshot dependencies of this build
configuration), allows choosing a branch to be used for the custom
build.
Both imply that branches from snapshot dependencies should show up in the Run Custom Build dialog. But they don't. After playing around with this for a while, I can only get the pretty branch tags to appear in the UI if my dependant project has the same VCS root attached (even though it doesn't even use any source in its build steps).
Is this a bug or am I misunderstanding something about TC?
I'm using TC 9.1, with git/branch specifications.
Related
My build configuration pulls code from multiple vcs roots. As part of my build process I build an open source project from github, which unfortunately has just introduced a dependency that breaks the build on my server.
Is there any way I can change the specification of the VCS root to limit it to the commit before the dependency was introduced? I don't want to manually run a specific commit as this would force the other repository in the build back to the same point in time, which would mean I'm never building my latest code. For reasons outside of the scope of this question, I need to build all projects from source, so can't take a pre-compiled version.
Is it possible to force teamciy to always check out the same commit of a VCS root?
Most of projects are using tags to identify versions so probably you can use it.
Or if you always need only one version you can fork repo and add branch/tack on your copy
Unfortunately git refspec does not provide possibility to specify commit by hash.
I have question about correct configuration of VCS in TeamCity for projects.
I have a lot of small projects in one repository on GIT. It implies a lot of projects for one template in TC.
Because of that TC works very slow. For example 300 projects could compile all day.
I found the reason, in version control settings, when I want to download only one project from git I have to set checkout rules and define path to it.
This cause clearing and downloading new source codes for every compilation on TC.
When I clear checkout rules and TC agent download all repository it work fast and download only changes from git, not re-download all files of project like before. After this change projects compile 2h.
Problem with that configuration is showing changes in TC project for whole repository, when someone add new commit it appear to every project and is in history.
Do anyone know how to configure TC for working correct in that situation?
Additionally configuration issue which is necessary for every project is VCS for downloading external codes repository and common codes from the same repository where is project but different path.
For example:
C:\Projects\3rdPartySources\ - [for every project, different repository]
C:\Projects\src\ProjectA\ - [same repository]
C:\Projects\src\ProjectB\ - [same repository]
C:\Projects\src\ProjectC\ - [same repository]
Inside the VCS Checkout rules, you can specify specific rules like this:
+:Common
+:ProjectA
Or, you even can specify a custom variable :
+:Common
+:%PathToBuild%
Then, you will just have to set this var inside the "parameters" tab on each build configuration.
And, you will use the same checkout rules everywhere in your configuration.
I have been working with TeamCity, Jenkins and Bamboo my last 8years. Latest 2years very involved in ContinuousIntegration factory setup and mainteinance on my team with very good results, giving me a lot of habits about how to deal with builds, artifacts and pipelines.
Now, i'm on a new company, new team, new CI, TFS2015, first time for me.
Just one month before I arrive to this new team they were on TFS2012, with XAMLs, so I took the migration to vNext builds.
At first look, I found on vNext builds the classic build definition, i mean adding steps as a single task to the build, instead of monolithic XAML file.
But with the time, i was trying to create more complex builds, like TeamCity build chains, but this is not possible, strike one...
Then, I was trying to deal with multiple branches, one continuous build for each branch (we are on TFSVC), create packages from each branch, and I found I was duplicating my builds just to change repository paths and a few details, so I moved builds to templates trying to reuse build definitions, introducing variables to generates paths(for repos and branches) and versions and expecting to change only in one place the build and having this changes reflected in all builds derived from templates... but that's was not the case... :
variables are not accepted everywhere, like in repo paths.
can't change templates after created them, just replace them, and builds created from templates are not affected after template is changed.
strike two ?.....
I'm wondering if maybe I'm doing things wrong with TFS, maybe this is a different system and I can't do things like in other CIs.
Any advice in how to approach TFS to have a good, dynamic and reusable set of builds ??
here isn’t the feature that the changes of a build definition or template affects other existing build definitions.
If the build steps of build definitions are the same for each branch, you just need a build definition and add filters for each branch (Triggers > Continuous integrations (CI), after that it will uses corresponding source to build for CI build, for example, develop branch changes > Trigger a build automatically with develop branch source.
On the other hand, you can change branch and source version when queue build manually or through REST API.
If the build steps are different for each branch, you need to modify the definitions independently for detail requirements.
Here's the scenario: I have a TeamCity "master" build that aggregates the results of other 11 builds.
I'm using snapshot dependencies.
This works fine in normal scenario.But in case, any of the dependent sub build fails and master build is triggered again then all 11 dependent builds get triggered.I want only failed build to be triggered not all.
Is there any way to achieve this??
In TC 8, some settings will interfere with build reusing. From the docs:
Some settings in VCS roots can effectively disable builds reusing.
These settings are:
Subversion: Checkout, but ignore changes mode
CVS: Checkout by tag mode
Perforce: Checkout by label set to Client instead of Client mapping
Starteam: checkout mode option set to view label or promotion date
(source: https://confluence.jetbrains.com/display/TCD8/Snapshot+Dependencies)
Normally, if the source code for any of the 11 dependent fields has not changes ,they will be queued but will just silently go to success
In case you just need artefacts from the previous builds, you can try setting up artefacts dependencies instead of snapshot dependencies. That way you can rerun an intermediate target if it fails and still continue for the rest of the chain. By the way if you are setting artefact dependencies you also have to add "Finish run triggers" on the targets
Also, when setting snapshot dependencies, there is an option "Do not run new if there is a suitable one". Please enable it to see if it solves your problem
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.