For any Chef GitHub service hook to work, it will need to parse out what files were modified, added, and removed; determine the correct actions to take (uploading / removing cookbooks, nodes, roles, etc.); clone/pull the repo to get the files to act on (or just grab the modified/added files from their raw download URLs); and finally sync up with the Chef server. I did some investigating into implementing that as a service hook. Here's what I found: The GitHub service hooks are all defined in this repo: https://github.com/github/github-services They are written in Ruby, unsurprisingly. So I guess this would involve two parts: 1. A web service that can accept GitHub service hook requests and take the appropriate actions. 2. The GitHub service hook itself that would just forward the payload to your Chef server (or hosted Chef) using some secure method such as mixlib-authentication. Ideally #1 would be built-in to Chef Server so using the GitHub service hook wouldn't require setting up yet another service. But that's a usability issue rather than an architectural one. It shouldn't be too difficult to implement all this, but I'm curious if Opscode has any opinion on the architecture and if they would be willing to accept a new component in Chef Server (including hosted Chef, since that is what I use) that can respond to GitHub payloads. Wes On Oct 5, 2012, at 1:57 PM, Noah Kantrowitz <
">
> wrote: It has been talked about a lot, would love to see it :) |
Archive powered by MHonArc 2.6.16.