Fix cleanup example to use pull_request_target trigger

[Mogyuchi]

Why:

Closes: #31321

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

• I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

  • For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

• For content changes, I have completed the self-review checklist.

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
actions/using-workflows/caching-dependencies-to-speed-up-workflows.md	fpt ghec ghes@ 3.11 3.10 3.9 3.8	fpt ghec ghes@ 3.11 3.10 3.9 3.8

---

fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server

[nguyenalex836]

@Mogyuchi Thanks so much for opening a PR! I'll get this triaged for review ✨

[corneliusroemer]

I tested this change and it does not fix the issue unfortunately

I still get the same error, at least when triggering manually (having added workflow_dispatch: to do so)

Maybe that's as expected, maybe the permissions are only granted when you merge a PR, hard to tell/test

I see, the right permissions might be auto-granted due to this change:

When a workflow is triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission, even when it is triggered from a public fork. For more information, see "Events that trigger workflows."
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

I've added explicit token permissions in #31582, this allowed me to test via workflow_dispatch:

[Mogyuchi]

@jc-clark
#31582 (comment)

What would you think of keeping pull_request as the triggering event here but adding a note above the example that links to "pull_request_target" and describes the cross-repo pull request use case?

No… I think we should use "pull_request_target".
Especially in public repositories, I think there is a possibility that cross-repo pull requests will be made even if the repository owner does not assume it. Therefore, I think we should present the example that takes into account the existence of cross-repo pull requests.