GitHub doesn't support custom server-side hooks, but we do support web hooks so you can run your own code on your own server in response to a push. You can find out more about our web hooks here: http://github.com/guides/post-receive-hooks <http://github.com/guides/post-receive-hooks> Tekkub GitHub Tech Support http://support.github.com/ Join us on IRC: #github on freenode.net Discussion group: [email protected]
On Wed, Jun 17, 2009 at 8:33 PM, shenkin <[email protected]> wrote: > > We're moving to Git from CVS. We want to version-control our hooks > with Git (hence the Subject: of this thread). We've come up with a > couple of ways to do it. If anyone has a better suggestion, we'd like > to hear it. > > We have about 10 product teams. Each product will have a "blessed" > repository used for continuous buildbot builds on our various main > development and release branches and also for official release builds. > We want each of these repositories to have the same set of hooks and > we want the hooks to be version-controlled by Git. > > For instance, we've written a mod of the contributed post-receive- > email hook that knows how to update our bug-tracking system when a > commit is made that affects a particular case. We'd like this hook to > be used by all our product repos, and updates to these hooks to become > immediately available in the product repos with a minimum of manual > effort. > > We'll have a Git repository called (say) "our_hooks". This will be > used to track the hook files (like post-receive-email). Developers > working on these scripts will be able to commit to the blessed > "our_hooks" repository's master branch, at which time we'd like the > new versions to immediately become available in the 10 or so product > repositories. > > Plan A. > > What we wound up with is this, which relies (unfortunately) on the > fact that (fortunately) all these blessed repos reside on the same > server and FS. > > 1. There will be a our_hooks.git bare repo to which commits intended > for immediate distribution will be pushed. > 2. There will be a our_hooks repo with working files; these will be > the actual files executed by the product repos. > 3. The files in the hooks dir of the product repos will be symlinks to > the working files in our_hooks. > 4. our_hooks.git will contain a post-receive hook that will cd to > our_hooks and pull the latest commit from our_hooks.git. > > We're not fond of symlinks, but the above will work, is simple, and is > our favored solution unless something better comes along. > > Plan B. > > This was the first one we thought of. It avoids symlinks and the need > for colocation of our_hooks with the product repos, but is more > complex. > > 1. We'll still have our_hooks.git, and it will be pushed to in the > same manner as in Plan A. > 2. Each product.git's hooks dir will contain a Git repository called > our_hooks, a clone of our_hooks.git with working files. > 3. Each product.git's hooks dir will also contain wrappers that do > nothing more than call the working copies in ./our_hooks. > 4. Each such wrapper will cd into ./our_hooks and do a pull from > our_hooks.git prior to calling the working file in ./our_hooks. > > This is a lot more work than Plan A (but what's work to a computer, > and "premature optimization", etc. etc.). But it's more complex than > Plan A, which is why we favor A. > > Plan C. > > Your move. ;-) > > -P. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
