Question: it doesn't seem that `Hook.execute` passes in ...

[sesas]

Question: it doesn't seem that Hook.execute passes in name, repo, user info to the script. How would a script contextualize a call?

How do you use this package in practice?

[sesas]

I am thinking that to use Django's signaling system should provide better extensibility potential (for example you could kick off a Celery Task for each call) and anyone would be able to customize what happens once the hook is triggered without having to modify the source of this package. What are your thoughts on this @sheppard?

[sheppard]

Thanks, these are both good points. My primary use so far has been custom build scripts for my papers, presentations and for the wq documentation. I don't have the actual deploy scripts checked in, but the basic workflow is pretty rudimentary:

# deploy.sh

#!/bin/bash
cd /path/to/existing/repo/clone
git pull
./build.sh

With a corresponding Hook instance configured in the admin:

• name = optional unless using URL-based lookup (added in Adds setup.py (python package information) #1)
• user = github username
• repo = repo name
• path = /path/to/existing/repo/clone/deploy.sh

The idea is that there would generally be one Hook for each repo, with everything configured through the Django admin, so I haven't yet had a need to pass the actual repo information on to each build script. Eventually that is something I would like to add - it would just be a matter of passing user and repo (and maybe some other variables from the payload) to hook.execute(), then passing that information on to subprocess.call() while taking steps to avoid the possibility of arbitrary code execution.

I like the idea of using signals a lot, though it would be a different use case. What I might do is add a signal.send() after line 28, and move everything from line 29 onward to a "default" signal reciever for backwards compatibility. Shell-savvy users who wanted to leverage the default reciever would just add github_hook to their INSTALLED_APPS (which they need to do anyway to get the Hook model and admin installed). Django-savvy users who wanted to set up their own signal receivers could just incorporate github_hook.urls without adding github_hook to INSTALLED_APPS.

It will probably be a few weeks before I get a chance to work on this myself, but if you want to put together a pull request (or two) I will definitely take a look at merging them and getting a new PyPI release out.

[sesas]

Thank you for this explanation. It makes sense now. I was wondering how to use this package to trigger CI builds or set pull request statuses on github but couldn't find a way to know which branch was being updated and send that to the script. This clarifies a lot.

Probably not this weekend but whenever my company has the next hack day I will try to use this as a smarter CI system than Jenkins and if I do I will submit a PR here. 😄

[sheppard]

See follow up in #7.