Conversation
On push to main the test job runs on the self-hosted runner, whose user has
no passwordless sudo. The step called `sudo apt-get` unconditionally, and CI
has no terminal, so it died with "sudo: a password is required" before it
could even report which tools were missing.
Pick an apt-get invocation that cannot block instead:
- root -> apt-get, no sudo at all
- passwordless sudo -> sudo -n (fails fast rather than prompting)
- neither, tools gone -> a clear error naming the tools and the two ways
to fix the runner, instead of a password prompt
The post-install check also reports which tool is missing rather than
printing a bare `command -v` result, so a partial install is legible.
The gate is unchanged: SCRATCHV_REQUIRE_RISCV_EXECUTION is still 1, so a
runner without the toolchain still fails the job -- it just fails with an
actionable message now.
Verified all four branches by extracting the step's script and running it
against stubbed id/sudo/apt-get.
Co-Authored-By: Claude <noreply@anthropic.com>
Nothing in a pull request ever runs on the self-hosted runner: both jobs pick their runner from the event name, so pull_request means ubuntu-latest and everything else means self-hosted. A change that only breaks on the self-hosted runner therefore passes review and fails on merge -- which is exactly how the RISC-V toolchain step in #73 got in green and turned main red. Add workflow_dispatch, which routes to self-hosted, so the path main actually runs can be checked without pushing to main. The schedule trigger is left commented out next to it: a cron would catch drift on its own, but it would also stay red until the runner is provisioned, so that is a call to make deliberately. The two `runs-on` lines now say which path they take, so the split is visible in the file rather than only in the expression. Co-Authored-By: Claude <noreply@anthropic.com>
🤖 AI Code Review
📁
|
Its push and pull_request triggers were both unfiltered, so a push to a branch with an open PR fired two runs for the same commit -- one for the push, one for the pull_request synchronize -- and both spent 15 minutes on ubuntu-latest. The two are not quite redundant (the pull_request run checks out the merge commit, the push run the branch head), but paying for both on every push is not worth it. Restrict push to main, the way ci.yml already does, and let pull_request cover everything else. A feature-branch push with a PR now runs once; a push to main still runs once. A feature branch with no PR now runs nothing until the PR is opened, mirroring ci.yml. concurrency does not solve this: the two events have different github.ref values (refs/heads/X vs refs/pull/N/merge), so no shared group key can collapse them. Co-Authored-By: Claude <noreply@anthropic.com>
No description provided.