Due to the intricate nature of managing indexing operations for multiple blockchains and their associated dependencies, the Launchpad project is a complex system with numerous interdependencies.
For a reminder of the various components within Launchpad and their intricate connections, we recommend revisiting our Intro.
This guide offers a comprehensive walkthrough, outlining the steps, automated and manual, required to introduce a new version release of an application, ie. Erigon, into the 'launchpad-charts' repository as a canary release and ultimately transitioning it to a stable state within its designated 'launchpad-namespace,' such as Ethereum.
The diagram below provides a visual representation illustrating the interdependence and impact of various components and workflows.
From new version to
Below you can find a more comprehensive breakdown of the process, divided into automated workflows within
launchpad-namespaces, as well as manual operator steps. This process guides the transition of a new application version from the initial
launchpad-charts canary release to its eventual stability within the corresponding
launchpad-namespaces. For this walkthrough we will use Erigon as an example.
- On each run, bot looks-up Erigon tags and upon finding a new version, opens a PR into
- The new PR triggers a workflow that publishes a new
pre-releaseinto the repo.
- Another workflow runs and adds the newly released
canarychart to the
canaryHelm repo index
- On each run, bot checks for new chart releases and upon finding one, pushes an update branch and opens a new PR to namespaces
- Bot runs again, auto-merges the PR and creates a tag
- Workflow runs, updates semver tags
- Tests the new
canarychart release to verify it is working properly, if it is adds commit to PR to set the
stablechart release version
- Updates their helmfile reference to point at new namespace reference and runs changes against
task releases:apply -- eth-goerli
- If the previous task runs successfully and workloads appear healthy, the operator updates their helmfile reference for
eth-mainnetnamespace and runs
task releases:apply -- eth-mainnet
task releases:apply -- eth-mainnetsucceeds and all workloads are healthy, operator manually tags the
Manually tagging a namespace as
stable is an intentional process. Our aim is to ensure that workloads undergo comprehensive testing before being tagged as
stable which signals to users readiness for running on
Alongside the ability to choose between
stable releases based on user risk preferences, we've also enabled the capability to manually override a specific chart version during namespace deployment.
- path: git::https://github.com/graphops/launchpad-namespaces.git@ethereum/helmfile.yaml?ref=ethereum-stable/latest
chartVersion: "0.8.1" # to override the chart version the namespace is setup with
Similarly to being able to override
chartVersion, users have the ability to override
chartUrl to specify a self-maintained chart, or a chart maintained by a different organisation.