Skip to content

Fix/ci riscv toolchain sudo - #80

Closed
jizhenjun wants to merge 3 commits into
mainfrom
fix/ci-riscv-toolchain-sudo
Closed

jizhenjun wants to merge 3 commits into
mainfrom
fix/ci-riscv-toolchain-sudo

Conversation

@jizhenjun

Copy link
Copy Markdown
Collaborator

No description provided.

jizhenjun and others added 2 commits September 26, 2026 22:22
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>
@github-actions

github-actions Bot commented Sep 26, 2026 •

Copy link
Copy Markdown

🤖 AI Code Review

共审查 2 个变更文件

📁 .github/workflows/ci.yml

🟡 Cache missing_tools result — Called twice: once in if [ -z ... ], again in echo "Missing tools: ...". Each call re-runs the loop.

missing="$(missing_tools)"
if [ -z "$missing" ]; then
  echo "RISC-V execution tools already available."
else
  echo "Missing tools: $missing"

🟡 Consolidate ::error:: annotations — Four separate ::error:: lines create four red annotations in the GitHub UI. One summary + regular echoes for details:

echo "::error::Cannot install RISC-V toolchain: runner is not root and has no passwordless sudo."
echo "Tests need clang, ld.lld, qemu-riscv32. Either preinstall on the runner:"
echo "  apt-get install --no-install-recommends clang lld qemu-user"
echo "or grant the runner user passwordless sudo for apt-get."

💭 Commented-out schedule is misleading — The comment says it "will stay red until the self-hosted runner is provisioned." A weekly job that is intentionally red adds noise without adding signal. Either link a tracking issue or drop it.

💭 Comment volume — ~40 lines of comments across the diff. The context is genuinely useful, but the file is now hard to scan for the actual runs-on expression and toolchain logic. Consider trimming to 2–3 comments per section and moving the full rationale to a design doc or PR description.


📁 .github/workflows/topic06-benchmark.yml

Review

🟡 Consider expanding branch filter if release branches exist — Restricting push to [main] means pushing to a release/* branch will no longer trigger this benchmark. If you have any non-main branches where benchmarks should run on push (e.g., release cuts), add them to the list. If main is the only one that matters, the change is correct.

💭 Comment could be shorter — The 4-line comment is helpful, but something like this conveys the same info more compactly:

  # Restrict push to main to avoid duplicate runs with pull_request (same pattern as ci.yml)

The core change itself is clean and correct — this is the standard fix for the duplicate-trigger issue on PR branches. 👍


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>
@jizhenjun jizhenjun closed this Sep 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant