-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: a test framework for verifying upgrade of Zoe and ZCF #7966
Conversation
700e334
to
4f384fc
Compare
a7895a9
to
9b24615
Compare
ee15adb
to
1618fb4
Compare
9b24615
to
879104f
Compare
1618fb4
to
37ab31a
Compare
9c4771e
to
3b65d03
Compare
37ab31a
to
cde1e35
Compare
Build bundles locally, and add instructions for that. Fix prober script to survive when the prober was bundled with the helper version of atomicRearrange from the future, but it's run under an older docker image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please keep the context setup in the modules that use them. "supports" is meant for more generic code. If we ever need multiple bootstrap tests that use the same context setup we can re-evaluate.
/** @typedef {Awaited<ReturnType<typeof makeSwingsetTestKit>>} SwingsetTestKit */ | ||
|
||
export const makeTestContext = async t => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's only the context for test-vats-restart
. why move this from that module to this shared one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought there would be more sharing. I moved it back.
|
||
// to retain for ESlint, used by typedef | ||
E; | ||
|
||
// main/production config doesn't have initialPrice, upon which 'open vaults' depends | ||
const PLATFORM_CONFIG = '@agoric/vats/decentral-itest-vaults-config.json'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should be in specified in supports
. Each test can choose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved with makeTestContext()
}; | ||
|
||
export const makeZoeTestContext = async t => { | ||
console.time('DefaultTestContext'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider ZoeTestContext. but also, why put in the common supports? It's used only one in test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed, and moved
const source = `${dirname}/${ZCF_PROBE_SRC}`; | ||
|
||
const zcfProbeBundle = await bundleSource(source); | ||
// uncomment and add `import fs from "fs";` to generate a bundle of the prober contract |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please clarify under what conditions someone would need to do this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's only needed to build the prober which will be used in the deployment test. Once it has been built once, and checked in with #8018, it won't need to be done again.
But the reviewer of that PR may reasonably demand the ability to reproduce the process, so we describe it here.
48340ce
to
6bea479
Compare
Build bundles locally, and add instructions for that. Fix prober script to survive when the prober was bundled with the helper version of atomicRearrange from the future, but it's run under an older docker image.
It starts from the currently installed version of Zoe and ZCF. First it verifies that reallocation via staging and via the helper work and that the version internal to ZCF is not present. It then upgrades Zoe and ZCF as necessary to introduce the new behavior. Finally, it re-runs the initial verification to show that the ZCF internal version works. This currently fails on the first step since it runs in a state in which the new Zoe/ZCF code has already replaced the old. Variants of this test will run on master without this PR to verify that upgrading to the new Zoe/ZCF works, and in deployment/upgrade-test to show that the upgrade to the new zoe & zcf will succeed.
6bea479
to
5813535
Compare
test: a test framework for verifying upgrade of Zoe and ZCF
refs: #6678
Description
a test framework for verifying upgrade of Zoe and ZCF. This includes bootstrap scripts that can be used to upgrade Zoe and ZCF.
The test starts from the currently installed version of Zoe and ZCF. First it verifies that reallocation via staging and via the helper work and that the version internal to ZCF is not present. It then upgrades Zoe and ZCF as necessary to introduce the new behavior. Finally, it re-runs the initial verification to show that the ZCF internal version works.
This currently fails on the first step since it runs in a state in which the new Zoe/ZCF code has already replaced the old. To check it in, we will change the parity of the test that the new internal
zcf.atomicRearrange()
is not present, since this version runs in an environment where that change has already been made.Variants of this test will run on master without this PR to verify that upgrading to the new Zoe/ZCF works, and in
deployment/upgrade-test to show that the upgrade to the new zoe & zcf will succeed. A copy of this code run on master without this PR, with bundles containing the new Zoe & ZCF code will show that the upgrade from the current state succeeds, and zcf's behavior in the probe contract will be different before and after.
Security Considerations
Validates the upgrade plan.
Scaling Considerations
None
Documentation Considerations
None
Testing Considerations
It's all about testing.