ci: add workflow_dispatch so CI can be run on demand - #11
Conversation
Enabling Actions on a repository does not retroactively create runs for events that already happened, and this workflow had no manual trigger — so after the Actions setting was turned on there was no way to prove it worked short of waiting for the next push. workflow_dispatch is also the honest way to re-run after provisioning a self-hosted runner or installing libz3, instead of pushing an empty commit to kick CI.
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_4dbb6e1e-ece7-40c9-bb4c-baf068eb2a06) |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_de7f4798-decb-4cdd-b87d-bb1a6eabf2a0) |
Why
Enabling Actions on a repository does not retroactively create runs for events that already happened, and this workflow had no manual trigger. So after the Actions setting was turned on there was no way to prove it worked short of waiting for the next push.
workflow_dispatchis also the honest way to re-run after provisioning a self-hosted runner or installing libz3 — rather than pushing an empty commit to kick CI.It already earned its keep
Dispatching against this branch produced run #1 — the first workflow run in this repository's history (33054949941). That confirmed the Actions toggle worked, which nothing else could have shown.
It also surfaced the next blocker immediately: all three dispatched jobs sit
queuedwithlabels: ["self-hosted"]— no runner is registered, so they wait rather than fail. "Queued forever" and "nothing happened" look identical from outside, which is precisely why an on-demand trigger is worth having.Timing note
This was pushed ~1 minute after #10 merged, so it missed that PR and is stranded on the branch. Same file, separate concern — #10 was the libz3 guard, this is the trigger.
Still open, not addressed here
scripts/setup-runner.shprovisions one (rust, radare2, libz3-dev); it then needs registering under Settings → Actions → Runners.releasejob did not dispatch — only 3 of 4 jobs appeared in the run. Worth checking for aneeds:/if:gate, though it's moot while nothing can execute.actions/checkout@v6is unverified. It's the first step of every job, so if that tag doesn't exist every job dies immediately. I could not confirm it —actions/checkoutis outside this session's repository scope. If the first real run fails with an action-not-found error, that is the cause and@v4is the known-good fallback.Generated by Claude Code