Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buidler-deployments plugin #381

Open
alcuadrado opened this issue Sep 20, 2019 · 2 comments

Comments

@alcuadrado
Copy link
Member

commented Sep 20, 2019

We should offer some functionality to preserve deployments' information between Buidler executions.

One possible solution is to create a plugin that extends the Buidler Runtime Environment with an object containing (at least) these two methods:

  • getDeployedContracts: Receives a TruffleContract and returns an array of contract instances. This method should warn if the deployed contract's bytecode doesn't match the local's one.

  • saveDeployedContract: Receives a contract instance, and saves its address. This method should warn if the contract was deployed to a testing/temporal network.

Under the hood, these methods should work with a JSON file looking something like this:

interface DeploymentsFile {
  [chainId: number]: {
    [contractName:string]: string[] // the addresses 
  }
}

Any operation involving reading & updating that file has to be synchronous, and, if possible, atomic.

Once we have this plugin, deployment scripts could be written in this fashion:

let [token] = await deployments.getDeployedContracts(Token);
if (token === undefined) {
   token = await Token.new();
   await deployments.saveDeployedContract(token);
}

let [other] = await deployments.getDeployedContracts(Other);
if (other === undefined) {
   other = await Other.new(123, token.address);
   await deployments.saveDeployedContract(other);
}

Writing them this way has the advantage of the scripts being resumable. If, for example, deploying Other fails because 123 wasn't a valid parameter, you can correct it and re-run the script without having to re-deploy the Token`.

Finally, other things that we should consider:

  • We should also have some methods to "forget" about a certain contract.
  • Should we store the deployment parameters?
@wighawag

This comment has been minimized.

Copy link

commented Oct 12, 2019

Hey,
You might want to checkout rocketh (https://github.com/wighawag/rocketh) it was optimized for a seamless deployment flow.

I am starting to look at buidler to see if i could implement the same functionality in plugins but I am not sure yet

rocketh supports the following thing :

  • stages (aka migrations in truffle parlance) that are run both for tests and deployment
    in test mode you can re-run them so your test can always act on a blank state. No need to duplicate code.
  • namedAccounts allow you to configure special account with name for each network.. Your tests can use them too. This make test more readable while preserving compatibility with deployment with real addresses.
  • when a failure happen while waiting for a deployment to be mined, rocketh save the tx hash so you can resume even for this case. When the stages are re-run It will wait for that transaction to complete. If this tx never finish, you currently have to delete the pending state. planning to add a prompt.
  • it saves a deployment file (only in non-test chain) that contains the solc output as well as the metadata. It also create a separate file for code verification that can be used as input for solc. These are meant to be stored on git and are used to check whether you want to redeploy a contract or not
  • Indeed it supports redeploy only if changes were made (checking arguments and/or bytecode) allowing you to feel confident in running the whole stages on the mainnet.
  • it supports bitski app wallet for deployment. You can have different wallet for the different networks
@wighawag

This comment has been minimized.

Copy link

commented Oct 12, 2019

Oh forgot to mention that it also support a keepRunning mode (running ganache or geth) using these features with the extra possibility of exporting the contract info (abi, address, [bytecode]) to an external file (path specified by user)

Very useful for local webapp development as you run it and then your contract are deployed and the info is available to your webapp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.