Try to find a comment to edit before creating #228
Conversation
| const getPRComments = `query getPRComments($owner: String!, $repo: String!, $number: Int!, $cursor: String){ | ||
| repository(owner: $owner, name: $repo) { | ||
| pullRequest(number: $number) { | ||
| comments(first: 20, after:$cursor) { |
There was a problem hiding this comment.
| comments(first: 20, after:$cursor) { | |
| comments(first: 100, after:$cursor) { |
I just put 20 to see if the recursive querying works.
| } | ||
| return githubClient.issues.createComment({ owner, repo, number, body }) |
There was a problem hiding this comment.
For sure like the looks of using GraphQL and promises 👍
| nodes { | ||
| name | ||
| } | ||
| } |
There was a problem hiding this comment.
Planning to use these labels for something?
There was a problem hiding this comment.
If we want to recognize a bot-out label, for complete opt-out.
|
Leaning towards keeping these changes instead of what I suggested in #226, especially when it comes to talking to the GitHub API. The other difference from the mentioned PR, is tests. You got any plans for more tests? |
That's my current WIP... mocking the GQL calls. (H/T to @gr2m for https://github.com/octokit/graphql.js/#writing-tests) |
|
Holler if you run into any blockers or have any questions about GitHub APIs / Octokit, happy to help |
|
@refack would you mind if I dived into getting a test in place, with the goal of getting this merged & deployed? |
phillipj
force-pushed
the
refine-pr-comment
branch
from
7212854
to
9e6f42c
Compare
|
@refack as I would really appreciate getting this landed soon, I took the freedom of rebasing with master to fix a PTAL |
|
I'd still prefer if the bot limited its commenting when possible. |
phillipj
force-pushed
the
refine-pr-comment
branch
from
8dfab1c
to
09b360f
Compare
|
Alrighty then, let's give this a test round to see how it behaves 🚀 Rebased and force push to fix conflict in |
|
This is now live in production. |
Reverting changes related to editing existing comments, going back to the previous behaviour of always creating new comments in PRs about CI / Jenkins runs. This is done primarily due to two things: * It has broken node-core-utils' ability to check if CI's have been run * There's not collaborator consensus about editing comments is actually better than creating new comments Future plans for bot PR comments going forward has to be discussed more thorougly and ensured it doesn't break other automation tools used by collaborators. Refs nodejs#228
Reverting changes related to editing existing comments, going back to the previous behaviour of always creating new comments in PRs about CI / Jenkins runs. This is done primarily due to two things: * It has broken node-core-utils' ability to check if CI's have been run * There's not collaborator consensus about editing comments is actually better than creating new comments Future plans for bot PR comments going forward has to be discussed more thoroughly and ensured it doesn't break other automation tools used by collaborators. Refs #228
@octokit/graphql