Custom Deployments #273

bh2smith · 2021-01-06T11:52:56Z

Addresses Issue #272 by allowing projects depending on this plugin to specify their own deploy function. If a deployment executor is not specified, then the initial (default) implementation is used as a fallback.

Currently this remains untested apart from the fact that all existing tests still pass. Open to suggestions for testing!

frangio

Hey @bh2smith, thank you so much for this PR. Sorry I took a while to get to this, I was focused on getting #261 done.

I think this is a really good idea and something I've also been thinking about. I've written some comments to explore the idea a little bit more before committing to it.

frangio · 2021-01-14T22:54:38Z

packages/plugin-hardhat/src/utils/deploy.ts

 import type { Deployment } from '@openzeppelin/upgrades-core';
-import type { ContractFactory } from 'ethers';
+export interface DeploymentExecutor {
+  (factory: ContractFactory): Promise<HardhatDeployment>;


Is there a reason this does not already return a "CoreDeployment"? In other words why do we need a HardhatDeployment with a ContractTransaction instead of the transaction hash.

I think the existence of intoCoreDeployment should be unnecessary.

So I can't exactly recall why this was necessary, but I believe it had something to do with the transformation of the proxy deployment from

const proxy = await ProxyFactory.deploy(impl, adminAddress, data);

into

const proxy = await deploy(ProxyFactory, [impl, adminAddress, data]);

and its return values not matching up. Notice how we don't use intoCoreDeployment on this particular line.

Ahh, yes, I believe I recall why we needed HardhatDeployment here is because at the time we pass the function onto the deployer, we do not actually have the transaction hash and the functionality of your code base requires a provider in order to fetch transaction by hash... Sorry if this isn't entirely clear just yet, but I will try again and see if I can remind myself exactly why this workaround was introduced.

I'd imagine the deploy function that was originally in this file would have been a perfectly good default DeploymentExecutor, returning the hash instead of the full ContractTransaction.

The reason I insist on this is that we currently have duplication of this layer across the Hardhat and Truffle plugins but we will want to merge those soon, and using the transaction hash is a more agnostic way to represent a deployment, instead of the Ethers-specific ContractTransaction.

Totally fine with me. I prefer to return only the hash any way. Have made the necessary adjustments and it also made the code on our end much more attractive and easy to write.

frangio · 2021-01-14T23:04:17Z

packages/plugin-hardhat/src/upgrade-proxy.ts

+import { defaultDeploy, DeploymentExecutor, intoCoreDeployment } from './utils/deploy';
+
+export interface UpgradeOptions extends ValidationOptions {
+  executor?: DeploymentExecutor;


I think this should be a "tx executor" and not only a deployment executor.

I'm thinking that for upgradeProxy it should also take care of sending the upgrade function call. What do you think?

Seems legit, I will look into this!

bh2smith · 2021-01-18T08:15:22Z

Hey @frangio and thanks for your response. I will attempt to address your questions/comment, thinking that only 1 of the two will be possible. I am, however, running into some awkward inconveniences with the return value of ContractTransaction from our end and will submit a draft PR pointing out this issue ASAP. At least then we will have a use case in mind and maybe get some impression of how to properly test this.

frangio · 2021-01-18T18:56:05Z

@bh2smith I took a quick look at your PR. Having to manually fill in the values for a ContractTransaction is definitely bad. It makes sense for the default deployer which simply does factor.deploy(...args) but for other kinds of deployments it forces you to fill in those values, returning only the transaction hash would be a lot easier.

Regarding your ignoring the factory argument, I understood that you will change that instead of hardcoding your contract inside the deployer, right? I didn't understand if that was motivated by a problem in the plugin.

I imagine you weren't able to use your branch because this is a monorepo. Unfortunately I don't know if there is a way to overcome that.

nfurfaro · 2021-01-18T19:06:23Z

Thanks for the work on this front. Really looking forward to being able to pass in a custom deploy function. Ideally, I would be able to use the deploy function (from the Hardhat-Deploy plugin) as my deploy function, as this makes so many things simpler(especially if you're already using the hardhat-deploy plugin in parallel with hardhat-upgrades).

https://hardhat.org/plugins/hardhat-deploy.html

bh2smith · 2021-01-19T07:56:10Z

returning only the transaction hash would be a lot easier.

Yes, I would really hope we can make a move towards this ASAP!

Regarding your ignoring the factory argument, I understood that you will change that instead of hardcoding your contract inside the deployer, right? I didn't understand if that was motivated by a problem in the plugin.

Yes, this is only temporary so I can see that the authenticator is actually upgradable

…upgrades into custom-deployment

bh2smith · 2021-01-19T10:12:26Z

@nfurfaro

especially if you're already using the hardhat-deploy

Yes, we are indeed!

bh2smith · 2021-01-19T10:13:16Z

I have reverted the introduction of the temporary HardhatDeployment and everything seems fine from this side. I will attempt to make out working example align with this and see how it looks.

…upgrades into custom-deployment

Closes #167 This PR introduces minor changes to the `AllowListAuthenticator` making it upgradable and includes tests verifying upgradability. In particular: - removing `customInitiallyOwnable` as it is no longer used: Not yet sure how this will affect the `deployments` directory which still includes it. - Updating authenticator deployment script to deploy as proxy. - rename authenticator `owner` to `manager` because of name collision with proxy owner - introduce proxy.ts with helper methods to fetch implementation and owner address. - Include two unit tests: one verifying that upgrade is possible and the other to ensure preservation of storage. Note that the unit tests involving Authenticator's non-upgrade related functionality do not use the proxy deployment as specified in the migration scripts, so that manager must be set immediately after deployment. We had originally planned/hoped to use the `hardhat-upgrades` plugin and opened the following two PRs to `openzeppelin-upgrades`, but this plugin turned out to be unnecessary. - Custom Deployments: OpenZeppelin/openzeppelin-upgrades#273 - Manual Safety Override: OpenZeppelin/openzeppelin-upgrades#280 ### Test Plan Old + new unit and e2e tests.

frangio · 2021-02-09T15:11:35Z

This is something we're interested in but are not prioritizing at the moment. If anyone is interested in this feature for their setup let us know!

Ratimon · 2021-06-14T01:04:01Z

This is something we're interested in but are not prioritizing at the moment. If anyone is interested in this feature for their setup let us know!

Yes, I am looking forward to using this feature

Amjad-W · 2022-04-11T13:23:49Z

I love this feature, will this merge pass through?

bh2smith · 2022-04-11T15:07:22Z

I love this feature, will this merge pass through?

This branch is now 10 months old. I think it should be considered stale. But you are welcome to brush the dust off and take over.

allow users to provide their own deployment implementation

cf991ce

frangio reviewed Jan 14, 2021

View reviewed changes

bh2smith mentioned this pull request Jan 18, 2021

Upgradable Authenticator gnosis/gp-v2-contracts#351

Merged

bh2smith and others added 3 commits January 19, 2021 11:02

Merge branch 'master' into custom-deployment

3901829

reverting introduction of contract deployment

2eed04f

Merge branch 'custom-deployment' of github.com:bh2smith/openzeppelin-…

da68e95

…upgrades into custom-deployment

bh2smith added 5 commits January 19, 2021 11:35

rename DeploymentExecutor to TxExecutor

8b724d9

allow users to provide their own deployment implementation

8d7fba2

reverting introduction of contract deployment

67b95de

rename DeploymentExecutor to TxExecutor

fb3acd6

Merge branch 'custom-deployment' of github.com:bh2smith/openzeppelin-…

ca259db

…upgrades into custom-deployment

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Custom Deployments #273

Custom Deployments #273

bh2smith commented Jan 6, 2021

frangio left a comment

frangio Jan 14, 2021

bh2smith Jan 18, 2021

bh2smith Jan 18, 2021

frangio Jan 18, 2021 •

edited

frangio Jan 18, 2021

bh2smith Jan 19, 2021

frangio Jan 14, 2021

bh2smith Jan 18, 2021

bh2smith commented Jan 18, 2021

frangio commented Jan 18, 2021

nfurfaro commented Jan 18, 2021 •

edited

bh2smith commented Jan 19, 2021 •

edited

bh2smith commented Jan 19, 2021

bh2smith commented Jan 19, 2021

frangio commented Feb 9, 2021

Ratimon commented Jun 14, 2021

Amjad-W commented Apr 11, 2022

bh2smith commented Apr 11, 2022

Custom Deployments #273

Are you sure you want to change the base?

Custom Deployments #273

Conversation

bh2smith commented Jan 6, 2021

frangio left a comment

Choose a reason for hiding this comment

frangio Jan 14, 2021

Choose a reason for hiding this comment

bh2smith Jan 18, 2021

Choose a reason for hiding this comment

bh2smith Jan 18, 2021

Choose a reason for hiding this comment

frangio Jan 18, 2021 • edited

Choose a reason for hiding this comment

frangio Jan 18, 2021

Choose a reason for hiding this comment

bh2smith Jan 19, 2021

Choose a reason for hiding this comment

frangio Jan 14, 2021

Choose a reason for hiding this comment

bh2smith Jan 18, 2021

Choose a reason for hiding this comment

bh2smith commented Jan 18, 2021

frangio commented Jan 18, 2021

nfurfaro commented Jan 18, 2021 • edited

bh2smith commented Jan 19, 2021 • edited

bh2smith commented Jan 19, 2021

bh2smith commented Jan 19, 2021

frangio commented Feb 9, 2021

Ratimon commented Jun 14, 2021

Amjad-W commented Apr 11, 2022

bh2smith commented Apr 11, 2022

frangio Jan 18, 2021 •

edited

nfurfaro commented Jan 18, 2021 •

edited

bh2smith commented Jan 19, 2021 •

edited