Add integration with Github/Bitbucket/Gitlab web hooks

[cweagans]

• Add a numeric story ID to each story and display it in the UI (I think this already exists in the database -- just needs to be displayed in the UI so that...)
• When a developer references a story ID in a commit that's posted to the webhook URL, appropriate action is taken on that story in Fulcrum (for instance, "Fixes #1234" in a commit message should do that same thing that clicking "Finish" on that story does).
• Add a note to the story linking to the changeset

This could be kind of challenging because Github, Bitbucket, and Gitlab all have different payloads that they deliver for web hooks.

[andreapavoni]

maybe it needs some kind of per-project configuration to set the proper web hooks. in this way, you'll have a modular system that supports thirth party services.

[mongrelion]

What about creating a gem per provider just like omniauth does for Facebook, Twitter, etc.?
Like fulcrum-webhooks or whatever.

[malclocke]

The long term goal for service integrations like these is to be API compliant with Pivotal Tracker. This means that anything that can work with tracker will work with Fulcrum with a change of URL. So for example with Github we would just modify the URL in https://github.com/github/github-services/blob/master/lib/services/pivotal_tracker.rb and get it added as a github service hook.

This of course relies on the service providers like github adding the hooks, and they may not all accept them, but I think the API compliance support is the best approach.

[kirantpatil]

💯 👍

[skinnyjames]

Should the commit information be stored as a note or reside in its own model? I'm thinking

class Commit < ActiveRecord::Base
    attr_accessible :commit_url, :author, :commit_message
end

class GithubCommit < Commit
end

class BitbucketCommit < Commit
end

as a way to avoid storing links in the note messages and separating different providers during view generation.

[andreapavoni]

@skinnyjames what about a provider field in Commit class ? :-)

if you want to to use different views on a per-provider basis, then you could do it anyway. for example:

<%= render partial: "commits/#{commit.provider}" %>

[skinnyjames]

@apeacox Agreed - STI was just proposed to keep options open in case different providers required different information (doubtful), and perhaps to make developing a service api more modular (the provider field storing a class rather than a string)
I'm interested in how commits should relate to notes or activity. Should a commit be a type of Note, or created separately and aggregated at runtime?

https://gist.github.com/skinnyjames/6055085

Any thoughts?

[andreapavoni]

@skinnyjames my reply in commented code https://gist.github.com/apeacox/6062010 :-P

[skinnyjames]

@apeacox :)

Here's working model using Grape API with a Github Service
https://github.com/skinnyjames/fulcrum/tree/api
https://github.com/skinnyjames/github-services/tree/fulcrum

It adds a commit model, github_commits API file & a controller
I don't know much about backbone (working on it) so I haven't touched the views, but I'm interested in what you all think.