Feat: Upgrade Callbatches

[odyslam]

Motivation

To realise an upgrade (and update the implementation address of the beacons) we need to execute some governance call batches,

Solution

Build a script that reads an updated configuration file (meaning that it has the new implementations) and produce the required call batches in a JSON file

PR Checklist

• [ ] Added Tests
• [x] Updated Documentation
• [x] Updated CHANGELOG.md for the appropriate package

[prestwich]

please fill out the motivation/solution sections. needs changelog too

[odyslam]

@anna-carroll removed all storage vars

[anna-carroll]

some thoughts:

• would be nice if this was written in a way that we could layer this on top of the current deploy implementations script, per some of @prestwich thoughts - the current workflow requires all of the deployments to finish, then update config, then run this script
• it would be a better workflow if the deploy implementations script could edit the config in-place, and then scripts like this could be layered on top of that and read from the updated config
• this is another point in favor of logic contracts operating on a single-chain basis; the entrypoint / script runner can loop through all chains, but it's easier to layer functionality on top of each other if the logic operates on one domain at a time

I feel like a Config.sol refactor that allows us to

• read config from file
• edit config in-place
• write the full values of an edited config to file would be super OP to make these scripts better to work with

[prestwich]

i generally dont apparove of updating a config in place. copy to new location and update at new location

On Mon, Nov 14, 2022 at 4:05 PM Anna Carroll @.***> wrote:

some thoughts:

• would be nice if this was written in a way that we could layer this on top of the current deploy implementations script, per some of @prestwich https://github.com/prestwich thoughts - the current workflow requires all of the deployments to finish, then update config, then run this script
• it would be a better workflow if the deploy implementations script could edit the config in-place, and then scripts like this could be layered on top of that and read from the updated config
• this is another point in favor of logic contracts operating on a single-chain basis; the entrypoint / script runner can loop through all chains, but it's easier to layer functionality on top of each other if the logic operates on one domain at a time

I feel like a Config.sol refactor that allows us to

• read config from file
• edit config in-place
• write the full values of an edited config to file would be super OP to make these scripts better to work with

— Reply to this email directly, view it on GitHub https://github.com/nomad-xyz/monorepo/pull/530#issuecomment-1314377844, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNN4MPYTLNZEUZJPFQHSBTWIKSSXANCNFSM6AAAAAAR7LGVCA . You are receiving this because you were mentioned.Message ID: @.***>

[odyslam]

We can take some of the functionality from the multi-chain implementation deployment that replaced the configuration in-place. The ideal addition would be to first copy the configuration and the replace in-place.

[anna-carroll]

i generally dont apparove of updating a config in place

what if we didn't update the config file in-place, but the values in memory - then write the completed file at a new location at the end of the script