chore: dismiss Dependabot review requests

[Pigbibi]

What changed

• dismiss Pigbibi review requests automatically generated for Dependabot PRs
• recognize both dependabot[bot] and app/dependabot identities
• require the review-request event actor to be Dependabot
• re-check the latest Pigbibi review-request actor from the PR timeline immediately before deletion
• preserve later or concurrent review requests made by maintainers
• keep concurrent review-request runs instead of cancelling the matching cleanup
• use pull_request_target with metadata-only GitHub API access and no checkout

Why

These repositories already auto-merge eligible non-major Dependabot updates after CI, but CODEOWNERS creates redundant review notifications. Event-actor and timeline checks let the workflow remove only bot-generated requests without touching human review requests, including race conditions while a run is queued.

Validation

• verified automatic CODEOWNERS timeline actor on a historical Dependabot PR
• verified both supported Dependabot identities
• verified requested reviewer, event actor, and latest timeline actor conditions
• verified API errors fail instead of being treated as no match
• verified no checkout or execution of PR code
• bash syntax check
• git diff --check

[github-actions]

🤖 Codex PR Review

✅ Merge allowed: 1 finding(s) reported but none are blocking

ℹ️ Other Findings

1. 🟡 [MEDIUM] Logic in .github/workflows/dependabot_review_request_cleanup.yml

The gh api call only fetches ?per_page=100 from the issue timeline and then treats [-1] from that single page as the latest review_requested event. GitHub paginates timeline results, so on a PR with more than 100 timeline entries, a newer manual review_requested event for Pigbibi can be on a later page and be missed. If that happens while this run was triggered by Dependabot's automatic request, the workflow will incorrectly conclude the latest request still came from Dependabot and delete the current reviewer entry, removing a maintainer's manual review request. (line 38)

Suggestion: Paginate through the full timeline or request the last page before selecting the newest matching event. An alternative is to use a GraphQL query or gh api --paginate and compute the latest matching review_requested event across all pages before deciding whether to delete the reviewer.

---

Review by Codex PR Review bot • PR

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a33d5cc6d7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e7a43cb947

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 187ab3189c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Paginate timeline before treating actor as latest

For PRs with more than 100 timeline events, this requests only one API page, so the array does not necessarily contain the most recent review_requested event. If a maintainer's later request falls outside that page while an older Dependabot request is present in it, the workflow selects the bot actor and deletes the maintainer's currently pending request—the manual-review case this guard is intended to preserve. Fetch all timeline pages (or otherwise query the latest matching event) before making the deletion decision.

Useful? React with 👍 / 👎.