Is your feature request related to a problem? Please describe.
Our contract deployments are extremely complex which leads to unreadable deployment scripts & versioning difficulties.
Describe the solution you'd like
This issue proposes using a declarative approach to describing our deployments which fits in very well with our love for k8s.
Specifying a deployment is done using a deployment template. An example deployment template is:
{
"contracts": {
"MyContract_v1": {
"source": "MyContract",
"address": "0x4200000000000000000000000000000000000004",
"variables": {
"myVariableName": "{{ env.MY_VARIABLE_VALUE }}",
"isActive": false
}
},
"MyOtherContract_v2": {
"source": "MyOtherContract",
"address": "0x4200000000000000000000000000000000000006",
"variables": {
"myContract": "{{ contracts.MyContract_v1 }}"
}
}
}
}
env.MY_VARIABLE_VALUE gets templated in based on the process.env
contracts.MyContract_v1 allows you to refer to other contract instances which are deployed in the contract system that you are defining.
- The
address field (eg. "address": "0x4200000000000000000000000000000000000006",) is optional and only supplied on L2 where it is possible to up front define addresses used for contract deployments.
Example generated deployment config
Based on the environment:
- MY_VARIABLE_VALUE="great value very nice"
{
"contracts": {
"MyContract_v1": {
"source": "MyContract",
"address": "0x4200000000000000000000000000000000000004",
"variables": {
"myVariableName": "great value very nice",
"isActive": false
}
},
"MyOtherContract_v2": {
"source": "MyOtherContract",
"address": "0x4200000000000000000000000000000000000006",
"variables": {
"myContract": "0xRESOLVED_ADDRESS"
}
}
}
}
Completing this issue simply requires implementing the script which generates this config based on the inputs!
Is your feature request related to a problem? Please describe.
Our contract deployments are extremely complex which leads to unreadable deployment scripts & versioning difficulties.
Describe the solution you'd like
This issue proposes using a declarative approach to describing our deployments which fits in very well with our love for k8s.
Specifying a deployment is done using a deployment template. An example deployment template is:
{ "contracts": { "MyContract_v1": { "source": "MyContract", "address": "0x4200000000000000000000000000000000000004", "variables": { "myVariableName": "{{ env.MY_VARIABLE_VALUE }}", "isActive": false } }, "MyOtherContract_v2": { "source": "MyOtherContract", "address": "0x4200000000000000000000000000000000000006", "variables": { "myContract": "{{ contracts.MyContract_v1 }}" } } } }env.MY_VARIABLE_VALUEgets templated in based on theprocess.envcontracts.MyContract_v1allows you to refer to other contract instances which are deployed in the contract system that you are defining.addressfield (eg."address": "0x4200000000000000000000000000000000000006",) is optional and only supplied on L2 where it is possible to up front define addresses used for contract deployments.Example generated deployment config
Based on the environment:
{ "contracts": { "MyContract_v1": { "source": "MyContract", "address": "0x4200000000000000000000000000000000000004", "variables": { "myVariableName": "great value very nice", "isActive": false } }, "MyOtherContract_v2": { "source": "MyOtherContract", "address": "0x4200000000000000000000000000000000000006", "variables": { "myContract": "0xRESOLVED_ADDRESS" } } } }Completing this issue simply requires implementing the script which generates this config based on the inputs!