Write a tool for on demand mapping between github-handle, email and slack-handle

[neolit123]

this was discussed in the recent 1.11 Retro part 2 meeting:
https://youtu.be/sZekfvgIx28?list=WL&t=2076

me and @BenTheElder had a discussion about this today on slack:
https://kubernetes.slack.com/archives/C2C40FMNF/p1530819530000300
RAW copy-pasta of the discussion:
https://gist.github.com/neolit123/00835a9eec63de997329f0edf83977f6

also @dims proposed this tutorial about writing an Slack app.
https://github.com/slackapi/Slack-Python-Onboarding-Tutorial

The idea here is that sig-release need a tool to be able to find the email and/or slack handle of a user that submitted a PR, in case they need to directly contact said user about a certain PR related action.

one potential way of doing this is over a "slack-app", which is like a bot, except it has more power of what it can do. querying the slack app in the lines of give-me-email-and-slack-of <github-handle> or give-me-details-about-this-pr <PR#> would supposedly result into the app cloning the github repo and extracting email details for this committer. then it would also try to match the email used for the commit to the email used for the slack registration.

one big pitfall here is if the user has decided to set a dummy email in his git config user.email, which is not that uncommon.

right now, one reliable but manual way of finding the email of a member is by going here:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!forum/kubernetes-membership

searching for a github handle or a individual name and clicking over a user email and saying "i'm not a robot".

as suggested by Ben, i'm opening this is issue in k/community for a discussion about the options we have. possibly the implementation itself would go in k/test-infra.

/help
/kind feature
/cc @tpepper @jberkus
/cc @kubernetes/sig-testing-feature-requests
/cc @kubernetes/sig-release-feature-requests

[cblecker]

/remove-help

Removing help wanted, as there isn't an agreed to direction yet (doesn't meet the requirements for help wanted.

[neolit123]

in the meantime here is a quick script for the author/commiter emails from PRs:

https://gist.github.com/neolit123/f769f3c0c1d37f3e268cf71a1ffde1ab

# a shell script for retrieving emails from commits in kubernetes/<repo> PRs
# example usage:
#
# 	$ chmod +x ./get-pr-emails.sh
#	$ ./get-pr-emails.sh kubernetes <some-pr-#>
#
#	getting username and branch...
#	username = johndoe314314
#	branch = some-feature-branch
#	getting email addresses...
#	"name": "John Doe",
#	"email": "[email protected]",
#

[jberkus]

@neolit123 hey, thanks!

For some reason, on some PRs that shell script pulls in the full text of the patch. Haven't figured out why yet ...

[neolit123]

hi, @jberkus
i wrote it very quickly and it might not always work.

can you give me an example PR #?

[jberkus]

#64662

[neolit123]

@jberkus
thanks, script updated:
https://gist.github.com/neolit123/f769f3c0c1d37f3e268cf71a1ffde1ab

it's still possible for extra info to get grep-ed, but now it's less likely.

also:

# NOTE: the script uses unauthorized GitHub API access and has a rate limit
#       of 60 requests per hour.

[jberkus]

If someone needs more than 60 mappings per hour, they're not using it for the purpose we intended

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[jberkus]

/remove-lifecycle rotten
/lifecycle frozen

[nikhita]

Bumping this -- do we still want to have this? If yes, it'd be nice to have an agreed direction and then add the help wanted label. 😬

[neolit123]

i must admit i never had the need for such a tool, so it's up to sig-release to plan and own this item.

[cblecker]

/lifecycle frozen

If this isn't actively being worked on by sig release, then this should be allowed to close.

[nikhita]

If this isn't actively being worked on by sig release, then this should be allowed to close.

@cblecker I'm guessing you wanted to remove the frozen label so...

/remove-lifecycle frozen

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

Given the past activity on this, I don't think this is really needed. Closing, but please reopen if needed.

/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

Given the past activity on this, I don't think this is really needed. Closing, but please reopen if needed.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.