You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We do not currently test any cosmos governance when validating a chain software upgrade, especially one containing cosmos changes, and whether that remains compatible with existing instruction and tooling (such as a3p / synthetic-chain tests).
Description of the Design
Add an automated test executed at least during release validation, but preferably during any PR touching cosmos, exercising cosmos governance proposal, including listing pending proposal, making a deposit for the proposal, voting for it, and verifying it passes
This could be a simple governance parameters change proposal, a dummy swingset core-eval (see send-script.js) and/or a chain software upgrade.
The latter could be done after a release is cut in a3p-integration: create a new expected/future proposal in agoric-3-integration for the new release, switch the fromTag layer on master and/or release branch to this new upgrade, and verify the simulated upgrade on top of the newly cut release still works.
Security Considerations
None
Scaling Considerations
None
Test Plan
Described above
Upgrade Considerations
Testing upgrades
The text was updated successfully, but these errors were encountered:
@mhofman I'd like to get some more specific about what needs to happen when Cosmos protobuf definitions change so I can add an item to the Interchain Stack Upgrade Checklist.
Before we close this issue, we need an a3p test for software upgrades. The problem is that to simulate the upgrade flow, we need a version to upgrade to. Either we set a version that doesn't exist and just verify that the upgrade passed (software halted), or we upgrade to another upgrade plan name supported by the same software, but I'm not sure our upgrade logic currently handles that (depending on if the cosmos upgrade module forces a halt and restart or not)
In Agoric/agoric-3-proposals#120, we do such a manual test of a chain software upgrade for agoric-upgrade-14-rc1, but really this should be part of a3p-intergation. The above design constraints apply.
What is the Problem Being Solved?
We do not currently test any cosmos governance when validating a chain software upgrade, especially one containing cosmos changes, and whether that remains compatible with existing instruction and tooling (such as a3p / synthetic-chain tests).
Description of the Design
Add an automated test executed at least during release validation, but preferably during any PR touching cosmos, exercising cosmos governance proposal, including listing pending proposal, making a deposit for the proposal, voting for it, and verifying it passes
This could be a simple governance parameters change proposal, a dummy swingset core-eval (see
send-script.js
) and/or a chain software upgrade.The latter could be done after a release is cut in
a3p-integration
: create a new expected/future proposal inagoric-3-integration
for the new release, switch thefromTag
layer on master and/or release branch to this new upgrade, and verify the simulated upgrade on top of the newly cut release still works.Security Considerations
None
Scaling Considerations
None
Test Plan
Described above
Upgrade Considerations
Testing upgrades
The text was updated successfully, but these errors were encountered: