`stellar contract install|deploy` build the current project and install/deploy all built

[leighmcculloch]

What problem does your feature solve?

Currently, deploying a Soroban contract requires two separate commands:

stellar contract build && stellar contract deploy --wasm target/wasm32v1-none/release/contract.wasm

This is repetitive and error-prone. Users must remember the full path to the built wasm file, and if they forget to build before deploying, they may deploy stale code. This adds friction to the development workflow.

What would you like to see?

When stellar contract deploy is run inside a directory containing a Cargo.toml (i.e., a Soroban contract project), the CLI should:

1. Automatically detect that it's in a contract project directory
2. Run the build step (stellar contract build) if no --wasm argument is provided
3. Locate the resulting wasm file and deploy it

This would simplify the workflow to just:

stellar contract deploy

The CLI already knows how to build contracts via stellar contract build, so this would leverage existing functionality to provide a more streamlined experience.

What alternatives are there?

• Status quo: Continue requiring explicit stellar contract build && stellar contract deploy --wasm <path>
• Shell alias/script: Users can create their own wrapper scripts, but this adds setup overhead and isn't portable
• Makefile/just recipes: Similar to above, requires additional project setup

[leighmcculloch]

👋🏻 This would be pretty convenient I think.

[fnando]

Should we ask for confirmation before deploying contracts? Maybe we can ask for confirmation and have an optional --confirm to bypass it.

[tupui]

Should we ask for confirmation before deploying contracts? Maybe we can ask for confirmation and have an optional --confirm to bypass it.

Why? You call deploy to deploy, not build. But adding --build and --no-build could be good to @leighmcculloch 's point 👍 and default to build maybe.

I also have something in my makefile for that. I am going back and forth on the build no build no having a settings vs doing -o or not as I do now would be an improvement.

[fnando]

Why?

When you're deploying, you're explicit about the intent, by proving the wasm. I guess I'm just trying to keep the same intentionality.

But adding --build and --no-build

I'm 100% against mixing up build behavior through flags on the deploy command. If we're optimizing flows, it must be as simple as it can be. If they need this level of control, we should instruct users to use build+deploy with flags instead.

[tupui]

I'm 100% against mixing up build behavior through flags on the deploy command. If we're optimizing flows, it must be as simple as it can be. If they need this level of control, we should instruct users to use build+deploy with flags instead.

If we can do deploy without wasm and don't build then that's dangerous IMO as you are not necessarily sure about the state of the build.

[fnando]

right, that's why I'm against having --build/--no-build, and in favor of always building when no wasm is provided.

The remaining question is about deploy, not build: I'm on the fence about uploading multiple contracts without confirming (or using something like a --confirm).

wdyt, @leighmcculloch?

[leighmcculloch]

I don't think we need a confirm, build, or no-build option. If you're running deploy it's clear the intent is to deploy.

I think the real question is: when you're interacting with mainnet, should we have some sort of confirmation when any command is going to perform an operation? Maybe. And I think we should discuss that in the context of any command that performs an operation on-chain, rather than this one in isolation.

[leighmcculloch]

I've opened a separate issue to consider a confirmation step for all operations when interacting with mainnet:

• Add confirmation prompt for on-chain operations on mainnet #2375

[leighmcculloch]

I think we're also discussing that sometimes the stellar-cli may do something you don't expect and may be surprising. The CLI has the action log as a feature, but it is hard to use. To address this I think we can also make better use of audit logs as a concept. I've opened a separate issue for that:

• Add audit logs for network operations and key usage #2376

[tupui]

Yes and yes 🙌 very good ideas! And we need to figure out the key handling to me that should have a higher priority.

[willemneal]

Perhaps instead of the directory determining the deployed wasm, a -p or --package argument would signal that that would signal that the contract should be built.

The only downside I see to this is the added complexity of the arguments of deploy. If you can build with it then it would follow that you would need to be able to pass the required optional arguments to contract build. Thus deploy's arguments would become bloated.

One idea here is to use a metadata section in the Cargo.toml or a toolchain.toml like file to put those args. Personally I think this is better anyway as it would simply contract build too and allow you to not need to pass --optimize when you likely want that as your default.

[leighmcculloch]

The stellar contract build command has very few options. I think all the options could be included, and using clap's grouping feature to group the build options in their own section will make the --help still easy to navigate.