You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 16, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 16, 2022. It is now read-only.
Github + Badger API Integration for Automated Awarding #9
I think we can all agree that it is ideal to automate the badge issuance process as much as possible. A large number Badge criteria fulfillment hooks can probably be triggered by GitHub events (ex: Addition to a GitHub team, first commit, n-number of engagements with a repo, etc... See #8).
If we integrate with an issuer platform that exposes an open API (like Badgr, see #3) we can use (or create) a GitHub integration that awards badges automatically in response to GitHub events. New Badges that are issued in response to GitHub events should have to specify the exact hooks they respond to in their RFC (see #4).
In my many, many minutes-long Google-exploration, I did not find an Open Badges integration available for GitHub. The majority use case for Open Badges appear to be for formal and informal educational programs, not for open source contribution and engagement — despite it being a perfect tool for OSS community development!
If there is in fact no pre-existing way to automagically award badges based on GitHub actions, this would be an amazing contribution that Node.js can give back to the larger open source ecosystem, while we also scratch our own itch to ease long-term maintenance of Node.js Badges.
@williamkapke, you've had some experience with Github integrations via nodejs/community-committee#22. What are your thoughts on the feasibility, scope, and security concerns of what I've outlined above?
Github API token(s) are controlled by the @nodejs/build team. This should probably be integrated in the @nodejs/github-bot which worked with the them to get a token and server(s) for the bot. You'll want to get involved there.
A snag you'll need to work with is that org-wide events are not allowed for security reasons. This means you'd need to get a webhook setup for all repos individually.
@williamkapke I think that's doable too, I think GH allows you to get all the repos for an org. We could add a routine check to add hooks for any newly formed repos.
@ryzokuken prototype away 👍Excited to see what you create! Let me know if you need any help getting traction with the github-bot team or have any questions as you're implementing.
@williamkapke, does the org-wide event restriction include listening to team roster changes? That hook would be very valuable for this tool – ex: Awarding a TSC membership badge when a member is added to the organization's TSC team.
@amiller-gh It has been well over 2 days since I made the issue in https://github.com/nodejs/github-bot, and I have received no response yet. Could you please contact the team on a more personal level, make sure somebody helps me with the accesses we'd need to make this happen?
It looks like @phillipj is the primary code contributor, so he may be able to chime in here, or help point us in the right direction.
Otherwise, I'd seriously recommend just pulling down the app and experimenting with it! I don't believe you need any special permissions to get started here. I took a quick look at the bot app and here's what I've gathered (hopefully @phillipj can let me know if I have anything wrong!):
So, once you pull the repo down and get it started up, you would make a new endpoint(s) in the scripts directory (presumably scripts/badgr.js) that expects to be pinged in response to certain Github webhooks.
The tests directory contains integration tests for all the endpoints in the app. You would presumably add tests for the badgr endpoints here.
It appears that the more complex tests use fixture data to mock out the Github webhook responses for testing. You can add your own fixture data from the samples provided by Github.
It also uses nock and supertest to mock out HTTP requests. This would be used to mock out responses to and from Github and Badgr in our use case.
As for implementation details, it appears that many of the webhooks that we call don't return the user's public email address, so you may also have to hit up the Github API.
All that being said, you shouldn't need any permissions to start mocking out an end to end implementation and writing tests 🙂Does that help?
Activity
ryzokuken commentedon Mar 5, 2018
Badger's API: https://api.badgr.io/docs/v2/
GitHub's API: https://developer.github.com/v3/
GitHub webhooks (precisely what we need): https://developer.github.com/webhooks/
Node module for Badgr: https://www.npmjs.com/package/badgr-client
(This should work, atleast for simply issuing badges)
Node module for accessing GitHub's API: https://www.npmjs.com/package/@octokit/rest
Creating hooks using the module: https://octokit.github.io/rest.js/#api-Repos-createHook
@amiller-gh I believe I could prototype this, awaiting your approval.
williamkapke commentedon Mar 5, 2018
Github API token(s) are controlled by the @nodejs/build team. This should probably be integrated in the @nodejs/github-bot which worked with the them to get a token and server(s) for the bot. You'll want to get involved there.
A snag you'll need to work with is that org-wide events are not allowed for security reasons. This means you'd need to get a webhook setup for all repos individually.
ryzokuken commentedon Mar 5, 2018
@williamkapke I think that's doable too, I think GH allows you to get all the repos for an org. We could add a routine check to add hooks for any newly formed repos.
ryzokuken commentedon Mar 5, 2018
P.S. The I don't have access to view and/or contact the @nodejs/github-bot team ATM. Any alternative way to get involved?
williamkapke commentedon Mar 5, 2018
They're at https://github.com/nodejs/github-bot. Just open an issue 👍
amiller-gh commentedon Mar 6, 2018
@ryzokuken prototype away 👍Excited to see what you create! Let me know if you need any help getting traction with the github-bot team or have any questions as you're implementing.
@williamkapke, does the org-wide event restriction include listening to team roster changes? That hook would be very valuable for this tool – ex: Awarding a TSC membership badge when a member is added to the organization's TSC team.
williamkapke commentedon Mar 6, 2018
@amiller-gh I'll defer to @nodejs/github-bot team to make the call.
ryzokuken commentedon Mar 7, 2018
@amiller-gh It has been well over 2 days since I made the issue in https://github.com/nodejs/github-bot, and I have received no response yet. Could you please contact the team on a more personal level, make sure somebody helps me with the accesses we'd need to make this happen?
Thanks.
ryzokuken commentedon Mar 11, 2018
@amiller-gh any updates?
amiller-gh commentedon Mar 11, 2018
Hey @ryzokuken, sorry for the delay – busy week!
It looks like @phillipj is the primary code contributor, so he may be able to chime in here, or help point us in the right direction.
Otherwise, I'd seriously recommend just pulling down the app and experimenting with it! I don't believe you need any special permissions to get started here. I took a quick look at the bot app and here's what I've gathered (hopefully @phillipj can let me know if I have anything wrong!):
The project appears to be an Express app at its core and scripts are automagically loaded from the scripts directory.
So, once you pull the repo down and get it started up, you would make a new endpoint(s) in the
scriptsdirectory (presumablyscripts/badgr.js) that expects to be pinged in response to certain Github webhooks.The tests directory contains integration tests for all the endpoints in the app. You would presumably add tests for the badgr endpoints here.
It appears that the more complex tests use fixture data to mock out the Github webhook responses for testing. You can add your own fixture data from the samples provided by Github.
It also uses nock and supertest to mock out HTTP requests. This would be used to mock out responses to and from Github and Badgr in our use case.
As for implementation details, it appears that many of the webhooks that we call don't return the user's public email address, so you may also have to hit up the Github API.
All that being said, you shouldn't need any permissions to start mocking out an end to end implementation and writing tests 🙂Does that help?
ryzokuken commentedon Mar 12, 2018