I’ve been trying to get our Unfuddle repositories to be smarter by notifying the CI server when something has been committed. To date, Unfuddle only supports there Callback URL functionality and not any sort of Git hooks.
Based on the specification from Unfuddle, they are doing a POST to the URL specified with data regarding the commit. Looking at the TeamCity specification, the URL they provide is wanting a GET. Since I’m not sure if TeamCity as actually looking for a GET or only accepting a GET, I decided to investigate further.
After opening up one of my favorite debugging tools, Fiddler, I looked at the POST request from clicking the “Run” button on the TeamCity interface. Upon doing so, I built the URL:
This tells TeamCity to run a build from the latest changes and add the comment: “Callback from Unfuddle”. The build type parameter is simply a reference to the build specification in TeamCity.
So, to test this theory out, I installed a Firefox add-on called HTTP Resource Test to test out actually a POST to this URL. This worked out perfectly. By build was triggered without a hitch including my build comments.
All that is left is to put my URL in the Unfuddle repository settings and away we go. I then made some commits on the local Git repository and then pushed those changes to Unfuddle. Waiting with bated breath, nothing happened.
Ok, what went wrong. I contacted Unfuddle support and it turns out that they aren’t passing QueryString parameters but the Callback URL was firing. So, back to square one.
At this point, I think my only option is to setup a proxy server to work with both parties. I looked at the Git hooks and there doesn’t seem to be a post-push (out of the box, there maybe an add-on/extension) that I can filter by pushing to Unfuddle to then run a script locally to do the GET or POST to the build server. Post-receive won’t work because again, Unfuddle can’t run hooks.
Anyway, when I get more time, I may investigate further and blog again about my solution.
Let me preface this with saying PEBKAC. I was the problem not ASP.NET. In fact, ASP.NET did exactly what it was suppose to do. So with that, here is my story…
I have spent the entire day trying to figure out why I’m no longer able to login to my website that I’m currently developing. I was able to login before (last week), what has changed. Time to follow the white rabbit down the rabbit hole.
My web application uses a common login site to authenticate me. In this case, I was using lets say login.mydomain.com. login.mywebsite.com is setup with a specified machine key. That way, I can login there and get a session cookie that can be consumed by thecoolapp.mydomain.com. This affectively provides me with a Single
Sign On Service (SSO).
I spent all morning trying to figure out why my version of ‘thecoolapp’ was unable to accept the cookie from login.mydomain.com. I re-cloned my code down to a temp folder and updated IIS to point to the new test site so see if there was an issue with the web application or possibly the application pool. No go. A team member did the exact same thing and his worked fine. At that point (and since we are using Git for our source control – hashed commits), I knew that it couldn’t be the source code since we were running the exact same code.
This can only mean one thing… its my machine. What the heck have I done (installed, setting change, etc.) since last week that may have caused this problem.
So, I uninstalled IIS and reinstalled thinking it would reset something. It didn’t. When that didn’t work I decided to take IIS out of the picture and try to run it using Cassini (Visual Studio Web Development Server). Oh wait, that can’t work because of my fancy login cookie stuff. See, login.mydomain.com sets a wildcard domain wide cookie and Cassini will only work with localhost. However, I added localhost.mydomain.com to my hosts file to point to 127.0.0.1. Let’s try this. Crap, it behaves just like IIS and DOESN’T WORK!
This led me to one conclusion. Windows Updates. I knew about the ASP.NET security update that Scott Guthrie mentioned here, here, and here. Maybe one more time would have done the trick .
Looking at the history, Friday evening, I applied KB2416471 and KB2416472. And then it hit me! Duh! What an ID10T! Of course it won’t work. login.mydomain.com doesn’t have the patch! (don’t worry, this isn’t a production URL and is currently in an intranet zone).
So, uninstall the patches, reboot and violas, I can login again. So, if you’re reading this, I hope you didn’t make the same mistakes that I did and remember what you installed on a Friday night.
I’ve been struggling trying to figure out exactly what settings I needed to use when setting up my TeamCity project using Git as the VCS/repository type and Unfuddle as the repository source.
I have my TeamCity server and build agent on one machine right now. Unfuddle currently requires me to use SSH to work with so I need to setup a key and register it with an Unfuddle account.
For anyone else having troubles with this, here are the settings that I used to get it working.
Obviously, select Git as the VCS Type
The General Settings section is basically the default settings from TeamCity. One thing to note is using the git@ forcing SSH. Be sure to have Git installed on your TeamCity server (I installed msysgit) and have port 22 outbound opened up to connect to Unfuddle.
The Advanced Setting is what took me a while to figure out. The things to note:
- I needed to use a Private Key for Authentication to connect to Unfuddle.
- Leave the user name blank
- Create a key and put it on the server. In my experience, you have to put a passphrase in the key. If you leave it blank, it didn’t seem to work.
I setup polling every 5 minutes. I’m not sure what the polling policy for Unfuddle is so you may want to change as needed.
That’s it. Click the Test Connect button and everything should work as expected.