build: install Cephes before running C benchmarks in CI

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• Fixes random_benchmarks CI, which failed on 8 of its last 9 daily scheduled runs (2026-08-08 back through 2026-08-01, only 2026-07-30 succeeded), each time on an unrelated commit SHA. Latest failure: https://github.com/stdlib-js/stdlib/actions/runs/31229597363, "Run C benchmarks" step, cc1: fatal error: /home/runner/work/stdlib/stdlib/deps/build/moshier_cephes/cephes/double/expn.c: No such file or directory, repeated for dozens of cephes/double/*.c files, followed by make: *** [.../c.mk:116: benchmark-random-c] Error 1.
  • Root cause: several packages (e.g. math/base/special/sinh) ship a Cephes-comparison C benchmark under benchmark/c/cephes/, compiled against a vendored Cephes copy that is not checked into the repo. It must be fetched via install-deps-cephes (tools/make/lib/install/cephes.mk: deps-download-cephes → deps-verify-cephes → deps-extract-cephes → deps-test-cephes) into deps/build/moshier_cephes/. tools/make/lib/benchmark/c.mk always passes CEPHES/CEPHES_SRC to the per-package build, but no workflow in .github/workflows/ ever ran a deps-*-cephes target. benchmark-random-c's only prerequisite is $(NODE_MODULES). When random_benchmarks.yml's random 10-package draw (RANDOM_SELECTION_SIZE=10) includes a Cephes-comparison package, the build fails; otherwise it passes, hence the high but not 100% failure rate.
  • Fix: added one step, "Install Cephes dependencies", to .github/workflows/random_benchmarks.yml, between "Run JavaScript and native add-on benchmarks" and "Run C benchmarks": make install-deps-cephes || make install-deps-cephes || make install-deps-cephes, timeout-minutes: 15. This is the same target run_affected_benchmarks already uses for the same purpose (.github/workflows/scripts/run_affected_benchmarks/run), and the triple-retry shape matches the existing "Install dependencies" step in the same file. 6 lines added, 1 file changed, no source or test changes.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• None.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

Validation: three independent automated reviews (correctness, regression scope, style/conventions) all returned approve, no blocking findings. Correctness confirmed deps-extract-cephes's default distribution (moshier) and build-output path match the failing run's error path, and that CEPHES/CEPHES_SRC thread through to the per-package benchmark Makefile correctly. Regression scope confirmed the workflow is not templated/called by any other workflow, has no job-level timeout at risk (steps sum to 165 of a 360-minute default cap), and nothing depends on deps/build/moshier_cephes/ being absent (gitignored, previously always empty in CI). Style confirmed the new step's formatting, retry idiom, and commit type (build:) match repo convention.

Reviewer note (non-blocking): the correctness reviewer flagged that install-deps-cephes's download step (curl -fkL) is not fully idempotent against an interrupted transfer — a truncated .zip left by one failed attempt is not force-refetched by a retry, so a mid-download failure could in rare cases survive all three retries and fail the C-benchmark step again with the same error. Acceptable: strictly better than the current 100%-reproducible-when-drawn failure, and matches retry semantics of every other network-dependent step in this workflow.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

This PR was produced by an automated CI-failure triage routine (Claude Code), which diagnosed the failure from live GitHub Actions logs and authored the fix. The change was reviewed by three independent automated passes before being opened as a draft for human review.

---

@stdlib-js/reviewers

---

Generated by Claude Code