-
Notifications
You must be signed in to change notification settings - Fork 208
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 #7969
Conversation
20f5b88
to
e9d808f
Compare
e9d808f
to
efd6de9
Compare
2787d2c
to
606ad23
Compare
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.
606ad23
to
1e6d52e
Compare
@turadg @dckc This test isn't intended to be merged. #7966 contains all the relevant changes that should become part of the source tree. The point of this PR is to demonstrate that #7966 would succeed in a repo that didn't already contain the changes to Zoe and ZCF. So: FYI, but not intended to be approved or merged. |
childProcess: processAmbient, | ||
fs: fsAmbient.promises, |
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.
modules should not export powerful objects (for example, objects that close over fs or process.env)
-- OCap discipline
Please let's pass powers such as fs
and childProcess
into makeTestContext
explicitly, if we're going to export it.
(yes, it's "just" test code, but I don't think this package as an exports
thing that prevents unwanted deep imports, so this is actually part of the public API).
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 converted the PR to DRAFT to make it clear that it's not intended to be merged. The point of the PR is to show that an upgrade from current state to post-ZCF would work. It's a rough copy of #7966, which is intended to merge, but has to start from the post-ZCF world.
It doesn't seem worth spending effort to clean this up, as long as it's convincing. Let me know if you'd like me to do it anyway.
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.
ah. thanks for clarifying. sorry to bother you.
Converting to DRAFT to indicate that this PR is not intended to be merged. |
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.
Variants of this test will run on top of the PR that updates Zoe and Zcf 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 continues to succeed.
Security Considerations
Validates the upgrade plan
Scaling Considerations
None
Documentation Considerations
None
Testing Considerations
It's all about the testing.