loambuild / loam

build, deploy, and maintain ambitious smart contracts. monorepo for Loam SDK, CLI, and shared tools.
https://loam.build
2 stars 7 forks source link

build-clients: in `staging` and `production`, require contracts to be IDs #76

Open chadoh opened 2 months ago

chadoh commented 2 months ago

In our example environments.toml file, we imply that staging and production environments will only allow contracts to be IDs.

[development.contracts]
soroban-atomic-swap-contract = { workspace = true }

[production.contracts]
soroban-atomic-swap-contract = "C987…"

However, right now in our tests, we only check the production environment, because that's the default for loam build, and we are using workspace = true for all the contracts.

We need to update our environments.toml parsing to only allow contracts to be strings, in staging and production. And we need to update our tests to check for this, and to make the current tests set development.contracts instead, and also set LOAM_ENV with them (and/or add the --env flag to cargo build—it's currently supported by build_clients.rs, but not added to build.rs, which is the actually-callable command).

BlaineHeffron commented 1 month ago

So just to clarify, we will never run deploy in production and staging? Because currently we just identify the contracts by name which should match the wasm file name and then get the contract id from deploying that wasm or using the alias if it already exists. So all of that should be skipped in production and staging environments, and we should throw an error if its not an already deployed ID?

chadoh commented 1 month ago

Correct, we will never run deploy in production and staging. It only makes sense to willy-nilly deploy in a development environment. By the time you get to production, you will want to deploy your contracts before you build your frontend for it. And since staging is practice for production, same thing.