ci: trigger benchmarks after LLGo main updates

[zhouguangyuan0718]

Summary

• notify xgo-dev/benchmarks after every push that advances xgo-dev/llgo:main;
• send the exact LLGo commit SHA in a repository_dispatch payload so the benchmark run pins that revision;
• default the destination to xgo-dev/benchmarks, with BENCHMARKS_REPOSITORY available as a temporary migration override;
• fail clearly when the dispatch token is not configured instead of silently skipping a benchmark.

Required repository setup

Add an Actions secret named BENCHMARKS_DISPATCH_TOKEN in xgo-dev/llgo. A fine-grained token should be scoped to the target benchmarks repository with repository Contents: Read and write permission, which is required for creating a repository dispatch event. The token is used only by this workflow and is never printed.

The receiver workflow is already merged into xgo-dev/benchmarks:main. After adding the secret, merge one small change to llgo:main and confirm that a repository_dispatch run appears in the benchmarks Actions history.

Validation

• rebased onto xgo-dev/llgo:main at d726187c;
• workflow YAML parsed successfully;
• generated dispatch JSON was validated with jq;
• git diff --check passed for the PR diff.

[fennoai]

Review: ci: trigger benchmarks after LLGo main updates

The workflow is well-constructed: permissions: {} (least privilege), the if: github.repository == 'xgo-dev/llgo' fork guard, set -euo pipefail, an explicit missing-token check, and jq -cn --arg for injection-safe payload construction. One reliability finding is worth addressing before this is relied upon; the rest are optional hardening.

Reliability (see inline comment on the curl call)

• The curl call has no retry or timeout. A transient GitHub API blip (5xx / rate limit / network drop) makes --fail-with-body hard-fail the job and silently drops that benchmark dispatch — the exact revision never gets measured.

Design decision to make explicit (non-blocking)

• No concurrency control: several commits landing on main in quick succession each fire a dispatch, causing redundant benchmark builds. Per the PR's stated intent (measure the exact LLGo version per commit), per-commit dispatch is likely intentional — but it's worth deciding deliberately. If only the latest main matters, add:

  concurrency:
    group: notify-benchmarks-${{ github.ref }}
    cancel-in-progress: true

Optional hardening (low priority, non-blocking)

• The token is set as a job-level env var. With a single step this is harmless, but scoping both env entries to the step keeps the secret out of any step added later (defense in depth).
• The token is passed to curl via --header "Authorization: Bearer ...", placing it in the process argv (visible via /proc/<pid>/cmdline). Negligible on GitHub-hosted ephemeral runners; matters only if this ever runs on self-hosted runners.
• Minor doc nit: the PR body's "Required repository setup" documents Contents: Read and write (correct for repository_dispatch) but omits the implicit Metadata: Read that fine-grained tokens require. GitHub usually auto-selects it, so this rarely bites.

[fennoai]

No retry or timeout on the dispatch call. A transient GitHub API failure (5xx, rate limit, or network drop) makes --fail-with-body hard-fail the job and silently drops this benchmark dispatch — the revision never gets measured. Consider adding resilience, e.g.:

curl --fail-with-body --location --request POST \
  --retry 5 --retry-connrefused --retry-all-errors --retry-delay 2 \
  --connect-timeout 10 --max-time 60 \
  ...

Pairing this with a timeout-minutes on the job is also a cheap guard against a hung call.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!