Revisit how we manage contracts repo for Engine partners
jakerockland opened this issue · comments
My inclination is that we may want to consider just having deployment scripts as something that gets stored in this repo for posterity, but not clone the contracts themeselves each time we do a new deployment.
I'd say that we consider this change as something we start doing with the introduction of V3 engine contracts into the wild–we could then migrate the DEPLOYMENT logs into the deployment script sub-dirs, and archive the contracts for engine contracts into a posterity folder.
Something warrant further discussion – happy to do async or sync @ryley-o – but just wanted to flag this as being worth consideration.
@jakerockland yes for this - we certainly don't need be compiling every engine contract forever like we are currently doing.
Would recommend that in addition to what you call out above, we start tying all contract deployments to github tags/releases. That would do wonders for us if we ever need to re-verify each contract's source code if, for example, etherscan were to disappear
Documenting the new deployment process is also part of this
I very much dig it.
This issue remains open until we implement the following:
- A V3_Engine command-line script that is able to deploy V3_Engine contracts with a simple input json file
- The script should also handle recording and archival of deployment inputs, logs, and source code verification
- (optional) The script may also be configured to configure any off-chain database metadata, if appropriate
This will enable a much more optimized deployment process, as well as facilitate a cleaner deployment history. These result in a better product that is more efficient to deploy