openzeppelin-upgrades
openzeppelin-upgrades copied to clipboard
OpenZeppelin
Custom Deployments
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!
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.
@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.
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
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
@nfurfaro
especially if you're already using the hardhat-deploy
Yes, we are indeed!
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.
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!
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
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.