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

Created on 5 Jul 2018 · 17Comments · Source: kubernetes/community

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

kinfeature lifecyclstale sirelease sitesting

Source

neolit123

👍1

Most helpful comment

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

nikhita on 25 Feb 2019

🎉1 👍1

All 17 comments

/remove-help

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

cblecker on 5 Jul 2018

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]",
#

neolit123 on 6 Jul 2018

❤1

@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 ...

jberkus on 13 Jul 2018

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

can you give me an example PR #?

neolit123 on 13 Jul 2018

64662

jberkus on 14 Jul 2018

@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.

neolit123 on 14 Jul 2018

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

jberkus on 16 Jul 2018

👍1

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 on 14 Oct 2018

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

fejta-bot on 13 Nov 2018

/remove-lifecycle rotten
/lifecycle frozen

jberkus on 14 Nov 2018

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. :grimacing:

nikhita on 24 Feb 2019

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.

neolit123 on 24 Feb 2019

/lifecycle frozen

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

cblecker on 25 Feb 2019

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

nikhita on 25 Feb 2019

🎉1 👍1

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 on 26 May 2019

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

/close

nikhita on 27 May 2019

@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.