Ask who opened the pull request, not who triggered the run - #4
Merged
Conversation
github.actor is whoever caused the run. Reopening a stuck Dependabot pull request to pick up a workflow fix made the actor a human, the job skipped, and the update sat there looking ready and never merging. Four came back with auto-merge skipping; two had to be merged by hand, which is the work this workflow exists to remove. The author never changes, and the author is what is being asserted.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
One line:
Why
github.actoris whoever caused the run, not whoever opened the pull request.So the moment a person touches a Dependabot pull request — reopens it, or nudges
it after the base branch moves — the actor is that person, the job skips, and
the update sits there looking ready and never merging.
That is not hypothetical. After the previous fix landed, four stuck Dependabot
pull requests were reopened to pick it up. Every one came back with
auto-merge skipping, because the reopener was a human. Two had to be mergedby hand — which is precisely the work this workflow exists to remove.
The author of the pull request never changes, and the author is the thing being
asserted: did Dependabot open this? Reading it from
github.event.pull_request.user.loginanswers that question directly.What breaks if this is wrong
Nothing loosens. The check still admits only pull requests whose author is
dependabot[bot], anddependabot/fetch-metadataerrors out on anything elseregardless. What changes is that a human can nudge a stuck update without
disarming the automation.
Note on the sequence
This is the third correction to this workflow, and all three were found by
running it rather than by reading it:
so the step died before queueing anything
update-type, which is empty for a grouped update — so no groupever qualified
request
If a fourth is ever needed, the answer is a reusable workflow in this
organisation's
.githubrepository rather than a fourth round of six identicalpull requests. Not done here: introducing a cross-repository runtime dependency
that cannot be tested until the next Dependabot run, in the middle of fixing the
thing it would wrap, trades a known small risk for an unknown larger one.