What I want to do:
I want to set up Continuous Integration with Team City for a project that's hosted on GitHub.
What's Currently Working
I'm properly connected to GitHub. Commits, pushing, etc etc all seem to be fine.
TeamCity is set up and I can kick off a build which will run and run my unit tests, but...
What's Not Working
When I do a TeamCity build, it looks like it's pulling down code from GitHub before doing the build or running unit tests. I want to trigger a TC build when I do a commit, before it does the push to GitHub. I don't really want it to pull any code out of GitHub before running the TC build. This doesn't seem to be working at all.
I've set up a BuildTrigger which is a VCS Trigger. I've checked the box that says Trigger a Build on Each Check-in. I added a rule to the BuildTrigger with the VCS (Github) source and my username.
When I do a commit, I don't notice TC doing anything. When I then push the commit to GitHub, TC doesn't do anything either. I see no builds queuing or anything like that.
Any clues on what I'm doing incorrectly?
Thanks!
Have you looked at TeamCity's pre-tested commit feature? It doesn't work exactly as you described you would like your workflow to operate, but it might be useful. I've used it with Subversion in the past and it works pretty well, I haven't used it with Git but JetBrains state it also works with Git.
However, the most common workflow for Git is to create feature/bugfix branches for everything you do, which allows you to commit and push freely, and merge to master when you are ready. GitHub makes the merge (and optional code review) step painless and TeamCity has built-in support to automatically build branches, see the TeamCity documentation on feature branches for specific details it provides.
Related
I'm using TeamCity 2017.1.4 along with GitVersion.
The teamcity project itself consists of many build configurations the first of which is to run GitVersion and then all subsequent steps take a snapshot dependency on this step and pull the version from its parameters.
In most scenarios this works great, however if we create a new branch eg. /release-foo and push this, teamcity will not trigger a build because its already previously built the commit sha, unfortunately we need it to trigger again as even though the commit hasn't changed being in a new branch means it will get a different GitVersion number.
I've tried forcing the snapshot dependencies on the GitVersion build configuration to always be rebuilt but this seems kind of ugly as kind of breaks all other scenarios where this isn't a problem. I also know I could manually trigger the build telling it to rebuild all dependencies and it would work, however I'm curious if there's a nicer way to get teamcity to automatically trigger a build for a commit on a branch if that branch didn't previously exist, or indeed any other way I could approach this.
You could try configuring TeamCity to include different/more GitVersion version variables in the build, including the branch name and possibly version tags. This would provide a way for your build process to differentiate between the same commit on different branches.
See steps 1-5 of this CD post, as well as this detailed blog post on using GitVersionTask for some examples on how to use the additional info in TeamCity.
You can achieve this by triggering the build from a git hook.
As explained here, you can use a the update hook to identify pushed branches (even when several are pushed in a single operation) and for each branch (assuming it passes your triggering rules) trigger a TeamCity build using the REST API.
If you simply amend the commit on the new branch without modifying anything, it will get a new hash because of timestamp changes. I wouldn't consider this a nice solution, but imho it's better than triggering manually.
We have a project on Snap CI but since it's going away we have to switch to another tool.
GoCD is our favorite but there is an important feature I am wondering if it's supported: Branch tracking.
Snap CI supports branch tracking which is currently enabled in our project: 'This repository has automatic branch tracking enabled for all branches starting with ***':
I tried to set up GoCD to do exactly this. But I couldn't find a way to achieve this behavior. The only thing I found was the feature branch / pull request plugin.
Do you know if such a feature is supported or how I have to configure the FB/PR plugin?
Thanks!
We wanted to do something similar and were faced with the same problem. In the end, we couldn't get direct branch tracking, but created a GoCD API client that created pipelines from a template, and the branch of Git material is set to a parameter (e.g. #branch). The client gets run manually when branches are created, but it could quite easily be adapted to run from hooks to automate it.
I'm dumb with continuous integration and noticed a behavior that does not seem right..
I'm using Mercurial with TeamCity. When I push changes the TeamCity detect the changes but don't run the build automatically. This is correct behavior? He should not detect the changes and run the build automatically?
Triggers are not added to build configurations by default in TeamCity. You'll need to go to the settings for the configuration and click on "Build Triggers" then "Add Trigger". The type of trigger I believe you are looking for is a "VCS Trigger".
The documentation for this feature can be found here.
I believe my issues was misunderstanding what was needed in Branch Filters. I thought I was supposed to enter the GIT refs I wanted to have builds triggered from
This wasn't working for me
+:refs/heads/*
-:refs/heads/releases/6.7.3
-:refs/heads/releases/6.8.30
-:refs/heads/releases/6.8.32
-:refs/heads/releases/6.8.34
And this is what finally figured out (I think) is that it is asking for the branch names inside TeamCity itself (the help text says "Newline-delimited set of rules in the form of +|-:logical branch name")
This worked for me, to trigger builds from the branch (GIT ref refs/heads/master for me, look back in your VCS Root setup) and all other branches except those labeled "releases/6.7.3", "releases/6.8.30", "releases/6.8.32" and "releases/6.8.34"
+:*
-:releases/6.7.3
-:releases/6.8.30
-:releases/6.8.32
-:releases/6.8.34
We'd like to implement CI using TeamCity.
We use Git for source control and would like to make use of the "pre tested commits" or "personal builds" feature of TeamCity.
Does anyone have experience with the VS plugin for Teamcity?
As far as I've seen, it only supports Subversion, no word about Git.
Anyone used this setup with any success?
As explained in Pre-tested “Commits” using Git by JoergM, you can emulate a solution similar to the TeamCity6.x "Personal builds on branches", by using personal repos:
.
There is one central Git-repository that only contains pre-tested changes. I call this “Green Repository” because it should only contain changes that lead to green builds.
Every developer pulls from this repository but nobody is allowed to push to it.
Instead everybody has a personal repository (think fork if you were on GitHub). The CI Server watches those personal repositories. After a commit it starts the compile and test. If that was successful it pushes the changes to the Green Repository.
JoergM adds:
The question is whether we will continue using our own solution or switch to the new feature of Teamcity.
So far I can’t see any advantage of the Teamcity feature.
With our solution we are even more flexible in regard of branch design.
This kind of setup is similar to what I described in "What is the cleverest use of source repository that you have ever seen?".
TeamCity 6.5 has new feature: remote run on a branch. It works for Git and Mercurial and does not require IDE, see more here: http://confluence.jetbrains.net/display/TCD65/Branch+Remote+Run+Trigger
Note that support for Git branches has been considerably improved in TeamCity 7.1. In my opinion, this is far better than the personal build feature.
The relevant docs are available here: http://confluence.jetbrains.net/display/TCD7/Working+with+Feature+Branches
I am a complete noob to this so if there is a completely obvious answer by all means make fun and point and laugh then give the answer.
We use Visual Studio 2010 to compile our published website. I have a repository that I use for my source code and one which I publish the compiled code to. I then check out the publish repository on the testing server and once it tests good I check out the repository on my main server. This is fine and all but I am using Tortoise SVN and automating the commit. Problem is, I really need to wipe the publish SVN repository, then copy the files, then commit. I just can't get that to happen and have it still recognize it as a SVN repository. Suggestions?
First of all, don't put compiled code into your source repository. It's bad form.
Look at Jenkins as a build server. Jenkins can use the msbuild.exe command to build .NET projects using the .sln file your project creates.
When you do a commit in Subversion, Jenkins will automatically fire off the build. If you have NUnit tests, Jenkins will run those and give you the results. You can have Jenkins store the compiled files for you in its archive. If someone wants to install a particular build, they can directly download it from Jenkins without having to do a checkout in Subversion first.
Jenkins offer all of these advantages:
It shows you all the changes in your repository and what changed in each commit.
It can run all sorts of tests automatically for you.
You can mark builds that are released using the "Simple Promotion" plugin.
You can tag builds in Subversion directly in Jenkins without needing a command line or working directory.
It can alert the developers if a build fails due to bad code, or if testing fails. These alerts can be done via Email, instant messaging, phone text messages, Twitter, and many other ways. All it takes is the right plugin which Jenkins makes easy to install.
Jenkins can act as a release repository which makes it easy to find the release, what's in the release and why.
Jenkins integrates with Bamboo, ViewVC, and Sventon. These are web-based repository browsers. This way Jenkins not only shows you the file changed, but what changed in the file.
Jenkins is easy to use and install. Download it and give it a try.
Unless you have a hard and fast requirement which forces you to use two separate repositories, i'd suggest taking a look at SVN tagging and branching functionality.
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html
Having a repository for the published code really doesn't buy you anything. IMO, you would be better off with a bunch of zip files (one per release) with the date and SVN branch reflected in the name. DO have a changelog .txt file in the zip, and also check that into the repo.
Problem is, I really need to wipe the publish SVN repository, then copy the files, then commit.
You don't need wiping in repo. Just make commit to production repo with exported HEAD from dev-repo (post-commit hook for commit message)
And tags, yes, are more natural and bulletproof way.