Unfortunately I don't think this works -- workflow_run always runs in the context of the "parent" repository, so the second hand of this && expression always evaluate to true (I think).

(But also, if the intention is to limit this to first-party PRs, then I think this workflow_run can be removed entirely and you can move these steps with their first-party check to ci.yml instead 🙂)

For what it's worth, if this works only for first-party PRs that would be a dealbreaker to me; we get lots of third-party PRs and even maintainer PRs often come from forks.

I wanted to follow zizmors advise below, in no way it should inhibit any PRs that are made onto here.

If you have to use a dangerous trigger, consider adding a github.repository == ... check to only run for your repository but not in forks of your repository (in case the user has enabled Actions there). This avoids exposing forks to danger in case you fix a vulnerability in the workflow but the fork still contains an old vulnerable version.

I ported their suggestion on github.actor == 'dependabot[bot]' && github.repository == github.event.pull_request.head.repo.full_name and ported it.
envoyproxy implements such a guard in two of its repositories.
https://github.com/envoyproxy/toolshed/blob/f70658cd0445b7d763107eaebde543be927c4f7a/gh-actions/github/env/load/action.yml#L45
and in envoy. Beside that it does not appear to be a common guard.

However, possibly they meant a hardcoded repository string, i.e. python/typing_extensions.
On third thought I now also think it might not make sense but leaving it here will have no negative consequences for this repo and all PRs against it.

I wanted to follow zizmors advise below, in no way it should inhibit any PRs that are made onto here.

If you have to use a dangerous trigger, consider adding a github.repository == ... check to only run for your repository but not in forks of your repository (in case the user has enabled Actions there). This avoids exposing forks to danger in case you fix a vulnerability in the workflow but the fork still contains an old vulnerable version.

This is my fault -- that advice is only correct for pull_request_target, not for workflow_run 😅. I'll file a bug to fix those docs later today.

(This is another datapoint for workflow_run being quite a footgun -- I think GitHub at one point also suggested this as a mitigation, which is where I got it from, without realizing that it doesn't actually protect anything on that trigger.)

Do you have any docs for this field? I couldn't find anything that clearly documents that it would point to the HEAD to the PR's branch, rather than the HEAD of the main branch.

(It's also not clear to me how this works when PRs contain some shared history or have identical commits due to cherry picking, so this feels pretty risky.)

https://docs.github.com/de/webhooks/webhook-events-and-payloads#workflow_run does not exactly specify it.
From my tests it always points to the latest commit in a PR which triggered the ci workflow.

For example: me as 3rd party no fork without access:
dsp-unima#9

A reference I found is here:
https://github.com/marketplace/actions/commit-hash

workflow_run events are handled by Workflows within the context of the main branch, therefore the github.sha context value does not represent the commit that triggered the Workflow and we must use the head_sha value on the event instead.