Contributing to Snowbridge
Processes for making changes to the Snowbridge pallets and runtimes for BridgeHub and AssetHub
Last updated
Processes for making changes to the Snowbridge pallets and runtimes for BridgeHub and AssetHub
Last updated
Any new code will be added to the Snowfork repositories:
- For adding/modifying contracts, off-chain relayer code, test net setup scripts and smoke tests.
- For parachain and pallet changes.
For both repositories mentioned above, pull requests (PR) should be made to the respective main branches. The Snowfork team members will review. Once the PR has been reviewed by 1 of more team members and all Github Actions pass, the pull request should be merged.
For any changes made to the , these changes should be contributed back to the original repository, .
To create an upstream pull request, do the following steps:
Check out the repository
Switch to the branch you would like to contribute upstream
Run `./bridges/snowbridge/scripts/contribute-upstream.sh my-changes`, where `my-changes` is the name of the new branch that will be created with your changes. The reason why this script creates a new branch is because we replaced Parity’s CI with our own, and so we need to clean up the changes that we have made to contribute the code back upstream. A new branch is created so it does not affect our CI and local development processes, but cleans the code so not to make irrelevant changes in the upstream PR.
Open the pull request on .
If the change is a minor change that doesn’t require release notes or greater awareness in Parity, ask on the PR in a comment for label R0-silent to be added to the PR. If the change is a larger change that requires awareness, add a file called `pr_xxx.prdoc` in the `prdoc` directory, where xxx is the PR number. Describe the changes in the prdoc file (look at examples in that directory - it is fairly straightforward).
Usually, the Parity bridges team will review the PR within a day or two, without needing to prompt. For urgent reviews, post the link to the PR in the Builders <> Snowfork Matrix Room, asking for reviews.
If the change needs to be deployed to Rococo immediately (outside a regular release cycle), also update the relevant runtime spec version. This is typically the or AssetHub runtime spec version. This spec version will automatically be incremented by Parity for release cycles.
Snowbridge pallets should be audited before releasing to Kusama and Polkadot. Audits should ideally be anticipated at least a month or two in advance, so that auditors can be engaged and booked in time. Since the overall codebase was audited, incremental audits will typically run for a week or less, with a week or two to address the findings, if necessary.
Audit fixes are usually done on a branch, so as not to interfere with other new features being built and to allow the auditors to easily verify fixes.
To deploy the change, extrinisc parachainSystem.authorizeUpgrade is called.
Once the referendum receives enough votes, parachainSystem.enactAuthorizedUpgrade can be executed to enact the upgrade.
The above steps are handled by Parity devs.
As part of the paritytech/polkadot-sdk release cycle, crates are published on crates.io. No extra action is required from the snowfork team to publish the Snowbridge crates. The crates are published by .
Rococo deployments are done after the polkadot-sdk release. If out-of-cycle deployments need to be done, they can be arranged in .
Once a new version of the polkadot-sdk is released, the polkadot-sdk crates should be updated in a PR to the fellowship runtimes repository. An example of such a PR is . Parity usually handles this and will push the release forward from the Fellows runtime PR to the execution of the upgrade on Polkadot.
A proposal to upgrade the runtime is created and can be viewed on Polkassembly (e.g. )