-
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
Cherry-pick core proposal and deploy-script-support changes #8747
Conversation
e5b374e
to
dd31b14
Compare
897f51b
to
26d198b
Compare
dd31b14
to
b31aa82
Compare
This is now ready for review. To measure against the goal of catching up |
c4cd927
to
8d3dc9e
Compare
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.
@@ -24,21 +31,21 @@ export const permits = { | |||
* definitions. | |||
* | |||
* @param {object} opts |
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.
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.
All of #8528 is cherry-picked.
5753e80 of #8712 is omitted as it depends on b735591 (of #8153)
I would love to bring both these in, but I start having tsc errors in inter-protocol's add-collateral-core.js
in that case. I actually do not understand how the errors don't happen in master
. When I look at the wrapInstall
in the default
export of add-collateral-core.js
in master (moved to the builders
package), all types seem to be any
. I suspect master
doesn't have type errors simply because we lost type coverage somehow there.
@turadg any idea?
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.
Getting type errors in init-core.js
as well.
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.
Confirmed. Fix in #8778
chore(types): correct ManifestBundleRef
refactor(agoric-cli): Improve git clone efficiency
test: drop obsolete tests
feat(cosmic-swingset): bundling and execution of `coreProposals` upon software upgrade
…ture of getManifestCall
…rs to "custom" (the former can be read like a verb)
* feat(cosmic-swingset): add being block check and transaction * fixup! feat(cosmic-swingset): add being block check and transaction --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
…salbehavior chore(deploy-script-support): Improve coreProposalBehavior.js
…in only when necessary
feat(deploy-script-support): Write out bundle file names in machine r…
…salbehavior chore(deploy-script-support): Sync code patterns across files
b31aa82
to
23dc128
Compare
I just rebased this PR on top of I will re-do the cherry-pick with the commits mentioned in #8747 (comment) restored, as well as cherry-pick the fix from #8778 @gibson042 if you want to informally review the result of the redo: 23dc128..8ae111d Edit: this PR has now been updated with the extra cherry-picks. |
23dc128
to
8ae111d
Compare
refs: #XXXX
Description
These are all the changes to bring
cosmic-swingset
anddeploy-script-support
roughly in sync with master. There are some things likely not strictly needed for getting core proposal working for chain upgrades, however the extra changes seemed harmless and getting to parity will help maintaining the branches in sync.Constructed from the following rebase-todo with minimal conflict resolutions:
Security Considerations
I don't believe there are any
Scaling Considerations
The core proposal runs blocking in the upgrade block, which could result in a slower upgrade block, but that has been deemed preferable to impacting later blocks.
Documentation Considerations
None
Testing Considerations
Test coverage should be maintained
Core proposal logic here has been tested by cherry-picking dd296e9 on top of this branch to simulate a core proposal installing the network related vats.
Upgrade Considerations
This introduces the ability to execute core proposals during chain software upgrades. There should be no impact to code running on chain, but it does support the ability to deploy vat upgrades as part of chain software upgrades in the release branch.