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
{{ message }}
This repository has been archived by the owner on Jul 13, 2022. It is now read-only.
when a cannonfile is updated, all of its deployments are nuked and paved.
This is actually probably right functionality for local chains. but for live network deployments, some protocols may have special requirements. additionally, projects which have not used cannon in the past (that is, all of them right now) should have a way to link their own deployments to their cannonfile without actually having cannon deploy them.
Introducing upgrade catalysts
When invoking the ChainBuilder, it will take in an option, upgradeCatalyst, which is a function (label: string, config: Config) => InternalOutputs | null that gets executed before the actual steps are executed. If the step should be skipped with alternate inputs, the upgrade catalyst returns the internal outputs that should be returned. Otherwise, it returns null.
cannon will provide a default upgrade catalyst for packages that have used cannon for a previous deployment but do not need to be deployed again. this will allow for general-purpose, minimal system upgrades without needing to redeploy everything, if that is how your protocol works. Alternately if the protocol is a type which has major upgrades which do not depend on the previous, the upgrade can be implemented that way as well.
The text was updated successfully, but these errors were encountered:
dbeal-eth
changed the title
fix cannonfile should not need to rebuild when changing only the version
implement upgrade catalyst functionality
Jul 1, 2022
when a cannonfile is updated, all of its deployments are nuked and paved.
This is actually probably right functionality for local chains. but for live network deployments, some protocols may have special requirements. additionally, projects which have not used cannon in the past (that is, all of them right now) should have a way to link their own deployments to their cannonfile without actually having cannon deploy them.
Introducing upgrade catalysts
When invoking the
ChainBuilder
, it will take in an option,upgradeCatalyst
, which is a function(label: string, config: Config) => InternalOutputs | null
that gets executed before the actual steps are executed. If the step should be skipped with alternate inputs, the upgrade catalyst returns the internal outputs that should be returned. Otherwise, it returns null.cannon will provide a default upgrade catalyst for packages that have used cannon for a previous deployment but do not need to be deployed again. this will allow for general-purpose, minimal system upgrades without needing to redeploy everything, if that is how your protocol works. Alternately if the protocol is a type which has major upgrades which do not depend on the previous, the upgrade can be implemented that way as well.
The text was updated successfully, but these errors were encountered: