Based on the existence of the config option "FIX_KEY_WORDS", it seems like this detects bugs just using keyword matching? Github also tracks when issues are fixed by commits (and pull requests, I think). Is it possible to use that metadata in addition to (or instead of) keyword matching? (Does Github even make that information available through an API?)
One way to support this would be to make FixCache support an optional hook that would be responsible for deciding if a given commit was a bug fix or not. Naively, it could have an interface like "IsBugfix(commit SHA1Hash) bool". The hook could be implemented as a function call to a used-defined plugin or something, or perhaps by executing an external process (e.g. shell exec my_custom_isbugfix.sh abcd1234")
Then users could write a custom hook that looked up the given commit using github's APIs or whatever other crazy scheme your team uses for bug tracking (e.g. cross reference JIRA ticket number baked into commit message with JIRA and look at the type of the JIRA ticket), but FixCache itself could be kept clean and pure from these integrations, which most users wouldn't want.
Github has lots of APIs, I'd bet it is possible to do this with github provided the data defining the relationship between the commit and the bug is encoded somehow -- either in commit message or in github issue or PR metadata or comment text.
The bugs are detected only from keyword matching in bug fix commits. The "FIX_KEY_WORDS" are fix key words in a fix-commit.
You set up a branch to track ("TRACKED_BRANCH") commits on (its 'master' by default). A history of commits, from last 30 days by default, is extracted from that branch on installation and bug fixes are detected from commit messages.
After installation, the app subscribes to push events (pull request merges are also push events) on the "tracked_branch" .On every push to the tracked branch, all the commits in the push are checked for bug-fix commits and the file cache is updated accordingly if there are any bug-fix commits.
Comments
Based on the existence of the config option "FIX_KEY_WORDS", it seems like this detects bugs just using keyword matching? Github also tracks when issues are fixed by commits (and pull requests, I think). Is it possible to use that metadata in addition to (or instead of) keyword matching? (Does Github even make that information available through an API?)
One way to support this would be to make FixCache support an optional hook that would be responsible for deciding if a given commit was a bug fix or not. Naively, it could have an interface like "IsBugfix(commit SHA1Hash) bool". The hook could be implemented as a function call to a used-defined plugin or something, or perhaps by executing an external process (e.g. shell exec my_custom_isbugfix.sh abcd1234")
Then users could write a custom hook that looked up the given commit using github's APIs or whatever other crazy scheme your team uses for bug tracking (e.g. cross reference JIRA ticket number baked into commit message with JIRA and look at the type of the JIRA ticket), but FixCache itself could be kept clean and pure from these integrations, which most users wouldn't want.
Github has lots of APIs, I'd bet it is possible to do this with github provided the data defining the relationship between the commit and the bug is encoded somehow -- either in commit message or in github issue or PR metadata or comment text.
The bugs are detected only from keyword matching in bug fix commits. The "FIX_KEY_WORDS" are fix key words in a fix-commit.
You set up a branch to track ("TRACKED_BRANCH") commits on (its 'master' by default). A history of commits, from last 30 days by default, is extracted from that branch on installation and bug fixes are detected from commit messages.
After installation, the app subscribes to push events (pull request merges are also push events) on the "tracked_branch" .On every push to the tracked branch, all the commits in the push are checked for bug-fix commits and the file cache is updated accordingly if there are any bug-fix commits.