dependabot / fetch-metadata

Extract information about the dependencies being updated by a Dependabot-generated PR.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Docs: Update Example to minimize Approval-notification-spam

fbartho opened this issue · comments

This action has an example for how to enable auto-approve:

fetch-metadata/README.md

Lines 68 to 72 in ffa0846

- name: Approve a PR
run: gh pr review --approve "$PR_URL"
env:
PR_URL: ${{github.event.pull_request.html_url}}
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

In our repo and many repos, a previous approval is not invalidated by a rebase. And the default example causes dependabot to auto-approve every time it rebases that PR, this approval appears as an additional email for subscribed viewers. So, every rebase causes an email for the rebase and an email for the approval.

Proposed alternative command:

(gh pr status --json url -q '.needsReview.url?' | grep "$PR_URL" && gh pr review --approve "$PR_URL") || echo "PR already approved, skipping additional approvals to minimize emails/notification noise."

This alternative command would skip the approval if the PR in question isn't present in the needsReview section of the JSON output for gh pr status.

In addition to feedback on this docs update, if my command isn't optimal, I'd love for advice for a better command to use in its place. This requires relatively sophisticated shell-expressions, and I'd love to simplify this, and make it more robust.

Warning Turns out, that that CLI command I proposed above doesn’t reliably work. So I’m still looking for a less-noisy solution to this problem if anybody has any advice?

@fbartho How about something like:

if [ $(gh pr status --json reviewDecision -q .currentBranch.reviewDecision) == "REVIEW_REQUIRED" ]; then 
  gh pr review --approve "$PR_URL"
else
  echo "PR already approved, skipping additional approvals to minimize emails/notification noise."
fi

Thanks @mwaddell! That looks great. I’ll try that out.

@fbartho - let me know if that worked, if so, I'll update the example in our documentation.

@mwaddell Looks like it's working! Thanks!

@mwaddell Actually, I spoke too soon. Looks like a bash error?

image

I looked into it a bit more, and it looks like this approach won't work until they fix cli/cli#575

👎

Bummer! Could I ensure our upstream is set for the repo or otherwise configure it for the purposes of this API call?

Bummer! Could I ensure our upstream is set for the repo or otherwise configure it for the purposes of this API call?

I think I figured out a workaround - see if #188 works for you. It looks a little silly to checkout the repo and then check it out again, but that's the only way to force the upstream to be set properly.

I can confirm that #188 fixed this issue for us! -- It took a moment to get new Dependabot PRs to verify everything was working!

Obviously we'd still prefer a technique that doesn't require checking out the repo twice, but this is a good workaround for now.

Thanks!