Skip to main content

TeamCity build triggering by GitHub

So I started using GitHub for a side project and discovered their very cool feature of service hooks. A service hook allows a repository administrator to setup a callback to another service when a commit is made to the repository. For example it can send an email, or chat a message via Jabber.

Now continuous integration servers, like TeamCity, can poll source control systems every few minutes to see if any changes have been committed. But wouldn't it be more efficient to use a service hook to trigger a build?

Looking at GitHub's service hooks, there wasn't one already available to callback a TeamCity server, but right on that same page was a link to the open source repository for GitHub Service Hooks. They "eat their own dogfood" so to speak and make it very easy to contribute new service hooks back to them. So I took an evening, did my first Ruby coding in a while which included more time getting Ruby setup and working on my Macbook than actually coding. In a few hours I had committed a TeamCity service hook to my fork of the project and requested them to pull the changes from my fork.

After just a few hours the pull was completed and the changes were in production, wow! Turned out I had a few bugs and it took some back and forth to get it all ironed out, but its now available as a working service hook at GitHub!

How to use the TeamCity service hook
Begin by creating a new account on your TeamCity host. Since this account will be used to kick-off the builds, its best to name it something like "GitHub Service Hook" so your developers will understand the build history when they see "Triggered by GitHub Service Hook". Note the username and password you create as it will be used later.

Next, navigate to your GitHub repository and look for the Admin button and click it.



Select "Service Hooks" from the left sidebar.



Select "TeamCity" from the submenu.


In the form that appears, enter
  1. the url to your TeamCity server (which can contain a path in the url if you run it on a shared host).
  2. the build type ID which you can find in the address bar when you are on TeamCity and looking at the build you want to trigger (ex. "...?buildTypeId=bt123&...", in this example the ID is "bt123").
  3. the username of the GitHub Service Hook user you created.
  4. the password of the GitHub Service Hook user you created.


Once you press "Update Settings", the page will refresh and you should see the "TeamCity" sub menu item change to have a green dot.

If you select "TeamCity" again, the form will reappear with a new "Test Hook" button. Press this and it will manually trigger the build with the information you entered.

The next time you push new commits to your GitHub repository, GitHub will trigger your TeamCity build!

Comments

Bradford K Hull said…
This is great! I'm trying to do this in a test case, so I can support TeamCity users on our GitHub Enterprise setup, but I've hit a curious snag. I don't know how to set up the TeamCity build to respond appropriately when the hook informs it there's a change. Right now, with no triggers or a trigger based on any change, it just sits there and does nothing when I hit Test Hook. What am I missing?

Popular posts from this blog

3D Photo Viewer for Looking Glass

The Looking Glass I created my first Chrome extension, which is now live on the Chrome Web Store ! It's built for the Looking Glass , a holographic display that let's you view three-dimensional objects without glasses. I've also opened the source to the extension on GitHub. The Chrome extension allows you to view Facebook's "3D Photos", a feature they added in 2018 for displaying photos that include a depth map like those from phones with dual cameras, such as Apple's "Portrait Mode". Getting Started To use the extension, connect your Looking Glass to your computer, navigate to Facebook and open the viewer from the extension's popup menu. This will open a browser window on the Looking Glass display's screen in fullscreen mode. Opening the Viewer Once the viewer is open, the extension watches for any 3D Photo files being downloaded, so browse around Facebook looking for 3D Photos.  I recommend some of the Facebook groups de...

Simplifying logging with Maven and SLF4J (Part 2)

So in my  previous post  I explained how to simplify your logging with Maven and SLF4J. If you haven't read it yet, please do before reading more.  Since then I've discovered an easier and cleaner way to remove the secondary frameworks from your Maven dependency tree. Here's a revised overview of the steps: Decided which logging framework will be your primary, aka who will actually write to your log file. Define the dependency scope of all the secondary frameworks to be ' provided '. Configure your project to depend on drop-in replacements of each secondary framework from SLF4J. Define secondary frameworks as provided Use the dependencyManagement section for this. Its used when you might have a dependency transitively. Add dependency on SLF4J Add the following to your pom.xml Conclusion So now in only 3 steps you can redirect all your logging to your primary logging framework without changing a line of code!

First Impressions from NoSQL Live

Today I drove up to Boston for the day to attend NoSQL Live . My experience so far within the NoSQL community has been limited to what we've built in-house at Disney and ESPN over the past decade to solve our scaling issues, more recently has been ESPN's use of Websphere eXtreme Scale , and the very latest has been my own experimentation with HBase which hasn't gotten much further than setting up a four node cluster. I've read a little about Cassandra, memcached, Tokyo Cabinet and that's about it. So before the sandman wipes away most of my first impressions of the technologies discussed today, I wanted to record my thoughts for posterity or, at the very least, tomorrow. Cassandra Cassandra seems to be the hottest NoSQL solution this month with press about both Twitter and Digg running implementations. My impression, I'm wary of "eventual consistency". I don't feel I understand the risk and ramifications well enough to design a system properly...