You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main motivation here is that we should make common development workflows as easy as
possible to do from within cargo-contract, instead of having developers make their own
wrappers.
There may be other subcommand we want to streamline, but this seems like low-hanging
fruit.
The text was updated successfully, but these errors were encountered:
One issue to decide with this is how to deal with all thebuild options. We can either
Accept all the arguments of both build and instantiate to the deploy command, though there may be some clashes e.g. --manifest-path.
Restrict the arguments allowed for build i.e. can only specify --release or --debug, all other options are default or inherited (in the case of --manifest-path)
I often find myself scripting something along the lines of:
cargo contract build --manifest-path flipper/Cargo.toml cargo contract instantiate --constructor new \ --suri //Alice --salt $(date +%s) \ --manifest-path flipper/Cargo.toml
We should add a
deploy
subcommand which is able to do both of these steps (and possiblemore if we think of anything else) in one go.
The main motivation here is that we should make common development workflows as easy as
possible to do from within
cargo-contract
, instead of having developers make their ownwrappers.
There may be other subcommand we want to streamline, but this seems like low-hanging
fruit.
The text was updated successfully, but these errors were encountered: