ci: add GHA to add PRs to project board when marked ready for review#5026
ci: add GHA to add PRs to project board when marked ready for review#5026MikeGoldsmith wants to merge 3 commits intoopen-telemetry:mainfrom
Conversation
The board's built-in auto-add workflow only fires on PR open/reopen, not when a draft is converted to ready for review. This GHA covers that gap by triggering on opened, reopened, and ready_for_review, skipping drafts. Assisted-by: Claude Sonnet 4.6
|
Please add the skip-changelog label. |
|
This is failing with |
…kflow pull_request trigger cannot access secrets for fork PRs (Secret source: None). pull_request_target runs in base repo context and can access secrets. Use otelbot app token (same pattern as backport.yml) instead of a PAT. No checkout step — intentional, see open-telemetry#4955. Assisted-by: Claude Sonnet 4.6
|
|
||
| on: | ||
| pull_request_target: | ||
| types: [opened, reopened, ready_for_review] |
There was a problem hiding this comment.
Do you know if opened and reopened won't conflict with the existing built-in workflow you had configured?
There was a problem hiding this comment.
They should be idempotent, but I plan to disable the workflows once this merges so they won't trip over each other.
|
FYI we're waiting on the following issue to make sure the credentials the action runs as has the correct access: |
|
This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment. |
Description
The Python PR digest board uses a built-in GitHub project workflow to auto-add PRs. However, that workflow only fires on PR `opened` and `reopened` events — it does not fire when a draft PR is converted to ready for review.
This means any PR opened as a draft and later marked ready for review is silently skipped and never added to the board.
Examples: The following resource detector PRs were all opened as drafts and missed the board as a result:
This GHA covers the gap by triggering on `opened`, `reopened`, and `ready_for_review`, while skipping drafts. Since it uses `actions/add-to-project` (which is idempotent), PRs opened as non-drafts are safe — they'll just be a no-op on the second trigger.
Security: `pull_request_target` trigger
This workflow uses `pull_request_target` rather than `pull_request`. This is intentional: `pull_request` does not have access to repository secrets for fork PRs (`Secret source: None`), so the otelbot token would never resolve. `pull_request_target` runs in the base repo context and can access secrets.
The workflow contains no `actions/checkout` step — it never executes any code from the fork, only uses the PR node ID to make a single GitHub API call. See #4955 for the full security discussion.
Prerequisites for org admins
Before this workflow will function after merge, an org admin must grant otelbot the Projects permission: