Obtaining the id of the bot user


#1

Hi there,

I would like to figure out the id of my App bot via some API. I can create a comment and look at the result, but would like a cleaner way to do this.

Is there a way to do this now? If not, should we consider adding support for GET /user ?

My current use-case is integrating with danger-js which uses the bot’s user-id to find existing comments that the user made. So if GET /user was made to work, then it would seamlessly work with the same APIs as with an OAuth token.

What do you think?


#2

Hi @clintam :wave:

My current use-case is integrating with danger-js which uses the bot’s user-id to find existing comments that the user made. So if GET /user was made to work, then it would seamlessly work with the same APIs as with an OAuth token.

I’m not familiar with danger-js and it would be great to re-phrase the use-case so that it doesn’t depend on that. Can you explain the use-case in terms of API endpoints being called (you said “which uses the bot’s user-id to find existing comments that the user made” – which API endpoints are being used for that?)?.

Thanks!


#3

Hi @izuzak

Have a look at https://developer.github.com/v3/issues/comments/

We can make calls to list the comments of an issue (GET /repos//issues//comments) as well to make new comment and update existing comment. When we create a comment the result will have a user.id property which (I assume) to be a globally unique id for our App’s bot user. All of this works fine and is consistent with when we authenticate with OAuth.

So imagine our bot POSTs a comment on an issue. Then at some point in the future we realize that we want to change that comment (perhaps to reflect the latest status of a PR). In order to identify the previous comment, we can look though the comment text to find some expected content, but it would also be nice to ensure that we are only updating a comment that we (our bot user) actually created. Thus it would be nice to search for existing comments where the “user.id” property matches our bot’s user id.

However, as noted above, the GET /user method is not available, so we have no good way to compute the bot’s user id.


#4

Thanks for sharing more details, @clintam! I’ll ask the team to consider this use-case and see if they have any thoughts. We’ll followup as soon as there’s any news.

I also wanted to ask a followup question on something you said:

So imagine our bot POSTs a comment on an issue. Then at some point in the future we realize that we want to change that comment (perhaps to reflect the latest status of a PR). In order to identify the previous comment, we can look though the comment text to find some expected content, but it would also be nice to ensure that we are only updating a comment that we (our bot user) actually created. Thus it would be nice to search for existing comments where the “user.id” property matches our bot’s user id.

To be honest, I’m not sure I understand why you’re searching for comments based on the user’s ID here. Instead, why aren’t you searching based on the ID of the comment itself? If you know you want to change a specific comment – then change that comment, and not just some comment that was authored by the same user and has the same content. Imagine a case where your bot created two comments with the same content. How would you know which to update?

Comment IDs are unique and using those to find comments you want to change seems like something you might consider. If you remember the ID of the comment, then you also know which user it was authored by because that can’t be modified (it’s not possible to change who authored a comment), so there’s no need to check the user ID.


#5

@izuzak its really quite simple: your solution requires state. The bot currently generates at most 1 comment per PR, so finding by the bot’s userid allows to avoid keeping track of pervious comment ids, and (due to the 1 comment per PR), does not loose any fidelity.

More, its how this existing project was working with the Github OAuth-authenticated API. So I think it is reasonable to expect that the same mechanism could work with using Github Apps.


#6

Thanks for explaining :bow:

More, its how this existing project was working with the Github OAuth-authenticated API. So I think it is reasonable to expect that the same mechanism could work with using Github Apps.

I wasn’t contradicting that. I was asking a clarifying question with the goal of offering a suggestion that might help you get to a working solution today (and a more reliable solution at that) instead of waiting for us to implement what you’re asking for.

Thanks for sharing your thoughts.


#7

Creator of Danger here: This did end up with a PR letting Danger work this way :thumbsup:


#8

Hello, just bringing this back up again because it’s still a bit of friction I wish I could automate away. A way I could see it working is to have the bot account referenced in the /app endpoint


#9

Another generalized use-case: if I have a code-review tool that enforces process by adding comments, and then deleting them when the process questions are resolved, it’d be nice for the bot to be able to simply look at the feed, and find the comments that apply to specific questions, and delete them. Obviously, we only want the bot to delete comments that belong to “itself”, so this feature would be nice.

One immediate argument against this workflow is that this might be better solved as part of the GitHub-checks API, but I assure you that that’s just a weakness in generalizing my example. The Github-checks API is only user-friendly to a point but when you have >N checks it can break down / if there are many things to fix, a few comments might be a better workflow.