Based on that information, we would need to confirm that we're actively tracking this repository and then update the appropriate issue tags in Firebase.
We'll want to handle the following cases:
[ ] closed
[ ] reopened
[ ] labelled (mostly done)
[ ] unlabeled
[ ] renaming an issue on Github updates the title on Firebase
[ ] ensure that creating an issue (with pre-existing label) triggers the labelled webhook (I would assume so, but am not positive)
I have setup a repo here: https://github.com/acorncom/ember-hitlist-tester to help with handling web hook notifications. If someone would like to be a contributor on it so they can add / remove labels, just let me know ;-)
Still needed:
[x] add logic for filtering issues down by repo (and watched tags per repo)
[x] refactor issue handler to have the pre-configured data store client injected (or passed in) from the index.js file (see PR #3)
[x] tests
[x] Firebase config
[x] work out Firebase data path. I was aiming for issues/repo-org/repo-name/<issue-id>, which should theoretically allow for doing a set for a given path (making updates completely controlled from our webhook) instead of needing to do updates. Would we then track "who is working on this issue" at a different path? Or should we move the issue down a level to /issues/repo-org/repo-name/<issue-id>/payload with /issues/repo-org/repo-name/<issue-id>/workingOn tracking contributors? How does this fit with setting Firebase permissions?
acorncom
commented
8 years ago
This issue is part of the initial MVP rollup issue for https://github.com/ember-learn/ember-help-wanted/issues/7
I believe we'll want to have an active web hook listening for this payload: https://developer.github.com/v3/activity/events/types/#issuesevent
Based on that information, we would need to confirm that we're actively tracking this repository and then update the appropriate issue tags in Firebase.
We'll want to handle the following cases:
labelledwebhook (I would assume so, but am not positive)I have setup a repo here: https://github.com/acorncom/ember-hitlist-tester to help with handling web hook notifications. If someone would like to be a contributor on it so they can add / remove labels, just let me know ;-)
Still needed:
index.jsfile (see PR #3)issues/repo-org/repo-name/<issue-id>, which should theoretically allow for doing asetfor a given path (making updates completely controlled from our webhook) instead of needing to do updates. Would we then track "who is working on this issue" at a different path? Or should we move the issue down a level to/issues/repo-org/repo-name/<issue-id>/payloadwith/issues/repo-org/repo-name/<issue-id>/workingOntracking contributors? How does this fit with setting Firebase permissions?