Release Issue Not Automatically Created for SessionInsights Repo #451
Description
hi @hdamker - I merged release_plan.yaml into the SessionInsights repo with this PR and did not see a release issue created from the automation. Did I do something wrong? I dug through the Actions tab and saw this Warning under "Report Validation Status":
Run actions/github-script@v8
Warning: Cannot post commit status — insufficient permissions (common for fork PRs). Validation result: Validation passed
Notice: Validation passed
- which is immediately followed by "Skip Validation - no release-plan changes"
I did initially create the update to release_plan.yaml from a forked repo, then put the PR from my branch in my forked repo back to origin/main at github. Could that be causing issues? Or maybe something wasn't done quite right in release_plan.yaml? I thought this change would trigger the release issue to e created.
Not sure if this is accurate or not, but this is what Claude told me:
❯ the automation on github was supposed to create a release issue but it didn't. Is there a way you can try to figure out what happened? I am digging through the Session
Insights Actions tab on github.com to try to figure out and did see this warning. I wonder if it is because the PR came from a forked repo and not from github directly.
Run actions/github-script@v8
Warning: Cannot post commit status — insufficient permissions (common for fork PRs). Validation result: Validation passed
Notice: Validation passed
Searched for 2 patterns, read 1 file (ctrl+o to expand)
⏺ The issue is almost certainly the fork PR restriction. Let me check the recent PR that triggered this to understand the flow better.
⏺ Bash(git log --oneline -10)
⎿ 2fd8d62 Merge pull request #76 from cablelabs/init/alpha-release
6d548de Merge pull request #75 from mohdfarhanakram/fix/session-insights-terminology
0bb1452 Add intent for alpha release
… +7 lines (ctrl+o to expand)
⏺ Here's what's happening and why:
Root Cause: Fork PR Security Restriction
Your diagnosis is correct. GitHub intentionally restricts write permissions for workflows triggered by pull_request events from forked repos. This is a security measure —
if fork PRs had write access, a malicious contributor could craft a PR that exfiltrates secrets or modifies the repo.
Looking at pr_validation_caller.yml, it uses the pull_request trigger (line 25-26) and declares issues: write, statuses: write, etc. — but those permissions are silently
downgraded to read-only for fork PRs, which is exactly what the warning confirms:
Cannot post commit status — insufficient permissions (common for fork PRs)
PR #75 (mohdfarhanakram/fix/...) and PR #76 (cablelabs/init/...) both appear to come from forks, so the reusable workflow couldn't post commit statuses or create the
release issue.
The Standard Fix
The reusable workflow at camaraproject/tooling would need to use pull_request_target instead of pull_request to run in the base repo's context with full permissions.
However, since this is a shared reusable workflow maintained by the camaraproject/tooling repo (not yours), the fix would need to happen there.
What you can do:
1. File an issue/PR against camaraproject/tooling to switch the trigger to pull_request_target (with appropriate security guards)
2. Manually trigger the release issue creation after merging fork PRs — check if the workflow supports workflow_dispatch
3. Require contributors to use branches in the main repo rather than forks (less practical for open source)
The workflow_dispatch option is already in your caller workflow (line 28), so you may be able to manually re-run the validation on main after merge to trigger the release
issue creation. Would you like to try that, or would you prefer I help draft an issue/PR for the tooling repo?
✻ Crunched for 30s