-
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
Agoric Upgrade 11 Tests -> JS #8237
Conversation
about the zoe upgrade (#8121) and injecting bundleIDs - in order for the upgrade core-eval to fit inside a chain upgrade, we need to use the agoric run / writeCoreProposal approach |
8eb2219
to
6fffcf2
Compare
6fffcf2
to
3d611f7
Compare
packages/deployment/upgrade-test/upgrade-test-scripts/agoric-upgrade-11/actions.mjs
Outdated
Show resolved
Hide resolved
packages/deployment/upgrade-test/upgrade-test-scripts/agoric-upgrade-12/actions.mjs
Outdated
Show resolved
Hide resolved
|
||
const dirname = dname(fileURLToPath(import.meta.url)); | ||
|
||
export const installBundles = async bundlesData => { |
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.
this seems useful in more than one actions file. consider putting in coreUpgradeHelpers
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.
return bundleIds; | ||
}; | ||
|
||
export const prepForCoreEval = async (filePath, constants) => { |
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.
ditto, consider keeping in a helpers module
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'm thinking that this code may go away, as we may move this approach to the agoric run
approach that was used for the wallet factory work
t.context.bundleIds = await installBundles(bundlesData); | ||
}); | ||
|
||
test.serial('Open Vaults', 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.
important but for a follow-up PR:
the actions aren't test themselves. They're always in a strict order, which isn't really what Ava's .serial
is meant for. (While it does execute in order, it's only guarantee is "not concurrently". Users should still be able to select any test in the file to run without the others.)
I think the actions module should just be a script without any Ava tests. In this file I see the only assertions are strict equality, which can be achieved with Node's built-in assert()
import { main } from './tools/vat-status.mjs'; | ||
|
||
test.before(async () => { | ||
console.log('Wait for upgrade to settle'); |
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.
should the actions of the preceding upgrade be responsible for 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.
I don't think so. I believe this here as we run pre.test.js
shortly after performing the actual upgrade (which happens after the actions of the preceding upgrade)
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.
what I mean is, the thing that is "performing the actual upgrade" has the job of upgrading. if the next step has to wait for the upgrade to settle, the the upgrade step hasn't finished it's job. The test should be able to assume the upgrade is complete. Knowing how much to wait for it to complete should be the responsibility of the upgrade, since it depends on the upgrade being performed.
packages/deployment/upgrade-test/upgrade-test-scripts/agoric-upgrade-12/tools/vat-status.mjs
Outdated
Show resolved
Hide resolved
packages/deployment/upgrade-test/upgrade-test-scripts/coreUpgradeHelpers.mjs
Outdated
Show resolved
Hide resolved
packages/deployment/upgrade-test/upgrade-test-scripts/agoric-upgrade-10/upgradeHelpers.mjs
Outdated
Show resolved
Hide resolved
bf79c61
to
6d54530
Compare
|
||
WORKDIR /usr/src/agoric-sdk/upgrade-test-scripts | ||
RUN yarn | ||
RUN echo '. /usr/src/agoric-sdk/upgrade-test-scripts/env_setup.sh' >> ~/.bashrc | ||
|
||
WORKDIR /usr/src/agoric-sdk/ | ||
|
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.
these lines complicate the boilerplate. Without templating it's hard to see what's supposed to be part of each layer vs what's specific to the current.
Would the following work?
WORKDIR /usr/src/agoric-sdk/upgrade-test-scripts | |
RUN yarn | |
RUN echo '. /usr/src/agoric-sdk/upgrade-test-scripts/env_setup.sh' >> ~/.bashrc | |
WORKDIR /usr/src/agoric-sdk/ | |
RUN cd upgrade-test-scripts && yarn | |
RUN echo '. /usr/src/agoric-sdk/upgrade-test-scripts/env_setup.sh' >> ~/.bashrc |
Also why does every layer need to append to ~/.bashrc
? Shouldn't doing it once at the top suffice? Hmm, ditto for the yarn install.
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.
Each build stage is seperate from each other, so the layers we add in agoric-upgrade-10
won't be present in agoric-upgrade-11
, which is why we have to do this for every stage.
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.
Oh, I thought they were layered upon each other. I still haven't grokked this scheme
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.
"core" has a particular association with "core eval". Is it used here just to mean ones that are common to all upgrades? please choose a different adjective like "common" or "shared".
@@ -0,0 +1,5 @@ | |||
import test from 'ava'; | |||
|
|||
test(`Replace me`, 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.
who, when?
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.
This should be replaced by the wallet factory work. The reason I have this filler here is because the runner expects to have a post.test.js
file present with at least one 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.
ok then please say that: replace with the walletFactory work when it's complete
packages/deployment/upgrade-test/upgrade-test-scripts/agoric-upgrade-12/post.test.js
Outdated
Show resolved
Hide resolved
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.
Good enough to land imo. We will keep iterating.
a9d117f
to
25351c9
Compare
25351c9
to
c270c4e
Compare
c270c4e
to
c5f7be4
Compare
Agoric Upgrade 11 Tests -> JS
refs: #8137
Description
Refactoring our bash scripts to look and feel more like Javascript. We've already competed
agoric-upgrade-10
. This change moves overagoric-upgrade-11
andagoric-upgrade-12
.Security Considerations
N/A
Scaling Considerations
N/A
Documentation Considerations
N/A
Testing Considerations
This change adds to our integration tests, which can be run with the
force:integration
tag.Upgrade Considerations
N/A