Open amiller-gh opened 6 years ago
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.
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.
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?
They're at https://github.com/nodejs/github-bot. Just open an issue 👍
@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 I'll defer to @nodejs/github-bot team to make the call.
@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.
@amiller-gh any updates?
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 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?
Thanks for looking into it, it does! I'll clone the repo, start a PR and we can iterate on it. I'll be dropping the link in here by today evening.
On Mon 12 Mar, 2018, 2:06 AM Adam Miller, notifications@github.com wrote:
Hey @ryzokuken https://github.com/ryzokuken, sorry for the delay – busy week!
It looks like @phillipj https://github.com/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 https://github.com/phillipj can let me know if I have anything wrong!):
The project appears to be an Express app at its core https://github.com/nodejs/github-bot/blob/master/app.js and scripts are automagically loaded https://github.com/nodejs/github-bot/blob/master/app.js#L35 from the scripts directory https://github.com/nodejs/github-bot/tree/master/scripts.
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 expect to be pinged in response to certain Github webhooks.
The tests https://github.com/nodejs/github-bot/tree/master/test directory contains integration tests https://github.com/nodejs/github-bot/blob/master/test/integration 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 https://github.com/nodejs/github-bot/tree/master/test/_fixtures to mock out https://github.com/nodejs/github-bot/blob/master/test/integration/node-labels-webhook.test.js#L29 the Github webhook responses for testing. You can add your own fixture data from the samples provided by Github https://developer.github.com/v3/activity/events/types/#memberevent.
It also uses nock https://www.npmjs.com/package/nock and supertest https://www.npmjs.com/package/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 https://developer.github.com/v3/users/#get-a-single-user.
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?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodejs/badges/issues/9#issuecomment-372146979, or mute the thread https://github.com/notifications/unsubscribe-auth/AMg3MuxGFOAzp2IyLi2_SCUjDjgX-TBAks5tdYq8gaJpZM4Sbi3b .
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 https://github.com/nodejs/badges/issues/8).
If we integrate with an issuer platform that exposes an open API (like Badgr, see https://github.com/nodejs/badges/issues/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 https://github.com/nodejs/badges/issues/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 https://github.com/nodejs/community-committee/issues/22. What are your thoughts on the feasibility, scope, and security concerns of what I've outlined above?