chore: dump fixtures without rewriting the global Solana config - #720
chore: dump fixtures without rewriting the global Solana config#720MarkFeder wants to merge 1 commit into
Conversation
Every `prepare.mjs` that pulls a program fixture from mainnet ran `solana config set -um` first, which writes mainnet into `~/.config/solana/cli/config.yml` and leaves it there. A plain `pnpm install` was therefore enough to silently repoint a developer's CLI, and the `deploy` scripts in these examples take no cluster flag, so a later deploy would follow it to mainnet. Passing `-um` to `solana program dump` scopes the cluster to that one command instead. Verified for both script styles (zx and stdlib) with the global config on devnet: the fixtures still download from mainnet and `solana config get` is unchanged afterwards.
Greptile SummaryThis PR scopes mainnet selection to each fixture download instead of mutating the developer’s global Solana CLI configuration.
Confidence Score: 5/5The PR appears safe to merge, with no concrete correctness, security, or compatibility issues identified. The changes consistently replace a persistent global CLI mutation with a command-scoped cluster option, and the supplied verification confirms both invocation styles still download the expected fixture without altering the configured cluster. Important Files Changed
Reviews (1): Last reviewed commit: "chore: dump fixtures without rewriting t..." | Re-trigger Greptile |
|
@amilz could you take a look at this one when you get a chance? No open review threads left on it, so it is ready for maintainer review. It is one of 23 open Pinocchio ports I have up — they are independent and self-contained, so they can be reviewed and merged in any order: https://github.com/solana-developers/program-examples/pulls/MarkFeder |
Repo-wide follow-up to a review finding on #719, in the same spirit as #702.
The problem
Every
prepare.mjsthat pulls a program fixture from mainnet ran this first:That is not a per-command flag — it writes mainnet into
~/.config/solana/cli/config.ymland leaves it there. Sopnpm installin any of these examples silently repoints the developer's CLI at mainnet, and since thedeployscripts here take no cluster flag, a laterpnpm deployfollows it.The fix
Drop the global mutation and pass
-umto the dump itself, so the cluster is scoped to the one command that needs it:8 files, two script styles (zx in seven, Node stdlib in
nft-operations/pinocchio). No behavioural change to what gets downloaded.The
deployscripts keep taking no cluster flag on purpose — they should deploy wherever the developer has pointed their CLI. That is only correct onceprepare.mjsstops moving the target underneath them.Verification
Ran both script styles in a container with the global config deliberately set to devnet:
tokens/create-token/anchor(zx, viapnpm install) →token_metadata.sodownloaded, 793,991 bytestokens/nft-operations/pinocchio(stdlib, vianode prepare.mjs) → same fixture, same sizesolana config getstill reported devnet after bothprettier --checkpasses on all 8 files.