-
Notifications
You must be signed in to change notification settings - Fork 102
Chain Upgrades
There is a relatively manual procedure that needs to be followed for updating the pre-built images when a chain upgrades.
Updates should be done in a fork of the repository, and PRs opened to the main repo.
When you know the new version that needs to be built, create a branch from current master named update-{chain}-{version}
.
Run a find and replace on the repository, searching for the previous version and replacing with the new version, and ensure you're only updating the chain in question (sometimes versions overlap).
Commit your changes to the new branch, and push to your fork. Open a PR against the main repository called Update {chain} to {version}
. When a PR is opened, the test suite is run to ensure the new version builds correctly.
In some cases you might need to change the GOLANG_VERSION
variable in build.yml
if this has changed.
Whenever a tag is added to the repository (forks or main repo), images are built for that tag. Using this you can publish an rc-*
tag to build the new images in advance of the PR being merged. This is useful for validators who need to update before the chain update is published to the main Omnibus repository. Usually the maintainers of Omnibus will publish one of these and include it in the PR description for people to use.
Typically I would create a new branch from master called release-{version}
, where version is the next Omnibus version (not to be confused with the chain version). I would merge any branches into this that are planned for the next release, and then tag this branch with {version}-rc1
. Pushing the tag to your fork will build new images for all chains.
Once the new versions have been tested and confirmed to work, the PRs would be merged to the main repo. Once all PRs have been merged, create a new release with the next version number, and 'auto-generate release notes'.
When the release is published, a new tag is created which triggers the chain images to build and publish.
Finally the documentation needs to be updated to point to the new latest release. Create a new branch from the latest master (with the new PRs merged) called update-docs-{version}
. Find and replace for omnibus:{old-version}
to omnibus:{new-version}
and update all files. The omnibus:
prefix ensures we only update the Omnibus versions and don't touch chain versions which again could overlap. Commit these changes and push to your fork, and open a PR.
Once the new images have all been built from the previous step, and tests are all passing, the docs update PR can be merged. Note that updating the docs means Cloudmos deploy tool will start to use the new images, so these need to have finished building before the docs update can be merged.