Basically, the problem there is that another instance of StakeManager was added to the deployment script to get access to it in the test environment for migration related tests. Now, whenever we want to run the deployment, we'll always deploy two StakeManager, which is not actually what we want.
In the context of the mentioned PR, this can be fixed by simply creating an instance of the migration stakemanager within the test environment and not touching the deployment script at all.
However, we still need a deployment script for deploying new versions of a stakemanager (without deploying them twice, or the VaultFactory).
Hence, I think it makes sense to add a dedicated deployment script, which essentially does what's added in the mentioned PR.
That deployment script can then also be used in the tests.
Something that came up in https://github.com/logos-co/staking/pull/69#discussion_r1505839973
Basically, the problem there is that another instance of
StakeManagerwas added to the deployment script to get access to it in the test environment for migration related tests. Now, whenever we want to run the deployment, we'll always deploy twoStakeManager, which is not actually what we want.In the context of the mentioned PR, this can be fixed by simply creating an instance of the migration stakemanager within the test environment and not touching the deployment script at all.
However, we still need a deployment script for deploying new versions of a stakemanager (without deploying them twice, or the
VaultFactory).Hence, I think it makes sense to add a dedicated deployment script, which essentially does what's added in the mentioned PR. That deployment script can then also be used in the tests.