Git commit monitor
almostautomated
regarding how spree's commit monitor links up Github and Lighthouse
for contributor's forked repos.
Thanks schof, appreciate the offer for help.
Thell
Sean Schofield
I've been meaning to blog about this for a while now. Since I still
haven't had a chance to write a proper post at least I can give you
some of the basic details.
I'm running the patch monitor application on Heroku (using the free
version.) Here are the only two files that you need:
config.ru (http://gist.github.com/207909)
app.rb (http://gist.github.com/207911)
The application file was heavily inspired by the existing Lighthouse
hook support[1] by Pj Hyett. My modifications allow any user to add
this hook to their fork without requiring that they have the full
read/write access token required by the built in Github approach.
This allows users to add [#123] to their commits and then issue #123
in LH will be marked patched and the relevant Github changeset will be
linked to the issue in Github.
The actual Lighthouse tokens, etc. are set as environment variables.
Heroku has a specific way to do this (see the excellent docs[2].)
This actually took quite a while to get it working properly. Here are
a few things that might save you some time and aggravation. One
problem I had with the testing was that either Github or Lighthouse
was throwing away some of the changes when they were identical to the
ones I pushed already. That made for some difficult debugging.
The other problem I discovered was that there was a known issue
related to branches. Github would often not detect changes on a
branch which was a problem b/c we typically create issues as separate
branches. They may have worked that out by now.
Good luck. Let me know how you make out!
Sean Schofield
---------------------------------------
Rails Dog LLC
5335 Wisconsin Avenue NW
Suite 440
Washington, DC 20015
voice: (301)560-2000
---------------------------------------
[1] http://github.com/pjhyett/github-services
[2] http://docs.heroku.com/config-vars
almostautomated
On Oct 11, 5:02 pm, Sean Schofield <s...@railsdog.com> wrote:
> Thell,
>
> I've been meaning to blog about this for a while now. Since I still
> haven't had a chance to write a proper post at least I can give you
> some of the basic details.
>
> ... My modifications allow any user to add
That's the part of your solution that most peaked my interest. While
many
people enjoy Github IIUC your solution makes it possible to
collaborate
using LH and GH without _having_ to have a GH fork. Nifty indeed.
> The actual Lighthouse tokens, etc. are set as environment variables.
> Heroku has a specific way to do this (see the excellent docs[2].)
> This actually took quite a while to get it working properly.
> related to branches. Github would often not detect changes on a
> branch which was a problem b/c we typically create issues as separate
> branches. They may have worked that out by now.
>
>
The have the branch issues partially worked out, a user must still be
pushing to a previously existing branch for the hook to trigger. This
isn't too bad for those in the know, but for new comers it is simply
an aggrevation.
I'll take some time this week and read those docs; been meaning to
become more familiar with heroku, so this is as good a time as any!
One other quick question for you... What do you have the spree.com
running on? A VPS, a slice, an open source hosted solution, ... ?
Thank you for sharing!
Thell
Sean Schofield
just don't have time to test right now but it was working pretty well
for us for a while. It would be nice if LH allowed you to implement
your own hook (and specify what types of changes were allowed.)
We use LiquidWeb[1] for hosting spreecommerce.com. So far I'm very impressed.
Sean