paritytech / paritytech/contract-dependency-manager

cdm deploy --dry-run: rehearse publishes (and initializations) without submitting

Open
#85 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
4
Forks
3
Avg merge
4d 13h
Merged PRs (30d)
3

Description

Motivation

Once migrations land (#77), the pre-publish testing story for an initialization is "deploy to a local PPN and see" — workable, but a rehearsal mode would make publishes (especially initialization-bearing ones) far less nerve-wracking:

cdm deploy -n paseo --dry-run

Sketch

Run the real pipeline up to (but never through) submission:

  • Build everything, resolve versions, compute the publish plan (what's up-to-date, what publishes, which initializations would fire and with what from).
  • Dry-run the composed extrinsics against the live node (ReviveApi dry-run calls / TransactionPaymentApi estimates) instead of submitting — surfacing reverts (e.g. a failing initialization) and fee/deposit estimates without touching chain state.
  • For initialization-bearing publishes: report the initialization's dry-run result explicitly (success/revert + return data decoded against the proxy/registry error tables).
  • Output the same DeployTable, marked as a rehearsal.

Notes / knowns

  • Node vs Bun diverge on ReviveApi.instantiate dry-runs (observed during #76 e2e work — instantiate dry-run was dropped from the harness for this reason); the dry-run path needs to pick runtimes/APIs that behave identically or document the constraint.
  • Dry-running a sequence (deploy impl → publish → migration) against unmodified chain state is inherently approximate for later steps that depend on earlier ones landing; either accept per-step approximation with a caveat in the output, or investigate chopsticks-style forked-state simulation for full fidelity.

References

#77 (initializations — the main motivation), #76 (deploy pipeline, batch composition).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the cdm deploy pipeline and the batch composition described in #76, then trace how DeployTable output is produced. Read the ReviveApi dry-run and TransactionPaymentApi paths, with initialization behavior from #77, and resolve the Node/Bun and sequential-state constraints. Done means a rehearsal output reports publish and initialization results, estimates, caveats, and no submitted state changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
blockchain, cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.