Triage: CI approval gate blocking PR #162 (fork PR, first-time contributor)
Hello @ApexChainx/maintainers — pinging the folks who can click "Approve and run workflows" on the Checks tab of #162.
What's blocking
This PR (closes #73, #92, #97 — assigned to @danfulani0) has zero workflow runs on it. Verified via the Actions API:
GET /actions/runs?branch=fix/danfulani0-issues-92-97-73 → total_count = 0
GET /commits/<sha>/check-runs → total_count = 0
GET /repos/.../pulls/162 → mergeable_state: dirty (downstream of no CI, not a real conflict; git merge-tree against origin/main shows zero textual conflicts).
Why it's blocked
This is a cross-fork PR (danfulani0:fix/danfulani0-issues-92-97-73 → main) and the repo's CI workflows use on: pull_request, not pull_request_target. Public repos in this configuration typically require a maintainer to click "Approve and run workflows" once before fork PRs can run.
What I (the PR author) tried (all 403)
gh run rerun — needs Actions: Write upstream.
gh workflow run ci.yml --ref <branch> — and ci.yml has no workflow_dispatch trigger anyway.
gh pr comment 162 (addComment) — danfulani0's integration scope is too narrow.
What a maintainer needs to do (≈ 1 click)
Open #162 → Checks tab → click "Approve and run workflows".
Once ci.yml queues and the failing step is visible, I can ship a targeted patch commit on the same branch fix/danfulani0-issues-92-97-73.
Optional faster path
If you'd rather skip the gate, a maintainer can merge the PR against a tracking-upstream branch (e.g. merge/162) from ApexChainx/main. That fires the push event workflows on the upstream branch and the logs are visible without the gate.
No code changes are needed here — only a single UI click on PR #162. Thanks!
Triage: CI approval gate blocking PR #162 (fork PR, first-time contributor)
Hello @ApexChainx/maintainers — pinging the folks who can click "Approve and run workflows" on the Checks tab of #162.
What's blocking
This PR (closes #73, #92, #97 — assigned to @danfulani0) has zero workflow runs on it. Verified via the Actions API:
GET /actions/runs?branch=fix/danfulani0-issues-92-97-73→total_count = 0GET /commits/<sha>/check-runs→total_count = 0GET /repos/.../pulls/162→mergeable_state: dirty(downstream of no CI, not a real conflict;git merge-treeagainstorigin/mainshows zero textual conflicts).Why it's blocked
This is a cross-fork PR (
danfulani0:fix/danfulani0-issues-92-97-73 → main) and the repo's CI workflows useon: pull_request, notpull_request_target. Public repos in this configuration typically require a maintainer to click "Approve and run workflows" once before fork PRs can run.What I (the PR author) tried (all 403)
gh run rerun— needsActions: Writeupstream.gh workflow run ci.yml --ref <branch>— andci.ymlhas noworkflow_dispatchtrigger anyway.gh pr comment 162(addComment) —danfulani0's integration scope is too narrow.What a maintainer needs to do (≈ 1 click)
Open #162 → Checks tab → click "Approve and run workflows".
Once ci.yml queues and the failing step is visible, I can ship a targeted patch commit on the same branch
fix/danfulani0-issues-92-97-73.Optional faster path
If you'd rather skip the gate, a maintainer can merge the PR against a tracking-upstream branch (e.g.
merge/162) fromApexChainx/main. That fires thepushevent workflows on the upstream branch and the logs are visible without the gate.No code changes are needed here — only a single UI click on PR #162. Thanks!