Build servers and source control are like the peanut-butter and jelly of devops; they just go together. That would make us suspect that it shouldn’t be that big of a deal to setup push notifications to trigger builds, right?
My GitLab instance shows that it will gladly trigger a build via web hook when it receives a new commit. My Bamboo shows that it will just as cheerfully scan for changes when it gets a web request. Couldn’t be simpler! Peanut butter and jelly. What could go wrong?
Well, for starters, GitLab and Bamboo use different message formats. GitLab sends POST request using its own format, whereas Bamboo expects notifications to come as GET requests in its format. The wonderful thing about standards.
Well, this simply won’t do. Let’s write a quick adapter to reformat our requests. Once again, Sinatra is my framework of choice for this. We’ll start by throwing together a Gemfile to provide Sinatra for us. Just remember to save it as “Gemfile” with no extension.
Next up, we’ll write a simple app.rb that will rewrite our requests for us. Our final code will take a POST request and rewrite it into the appropriate GET for Bamboo.
The meat of our code is the post. We’re defining the variable :buildKey as everything after the first slash. We then use that variable and some string interpolation to write out our GET query string. The last bit of magic comes from open-uri: it redefines open to allow it to work with URIs. We’ve effectively written a small proxy server to rewrite requests for us.
We can start it up with ruby app.rb. Now, GitLab can post to http://localhost:4567/The_Bamboo_Project_Key and the appropriate build should be triggered on our CI server.
Anyway, enough of this tangent. We’ll be back with our Fiddler series next week.
###Footnotes### [^1]: Had to pull in XKCD for this.