Add workflow to automatically create new node release

[b-yap]

Partially closes #456.

This workflow will do the following:

1. Perform a version up of the node
2. Create a new branch of the Cargo.toml change
3. Create a pull request with labels
   • if all packages are updated, the labels will be: release-node, release-amplitude, and release-pendulum
   • if only the node package is updated, the label will only be release-node

As we've never had a client release before, I've set this up to be triggered via the workflow. Like this:

The PR will look like this:

[b-yap]

@gianfra-t Yes. Ideally after this workflow, it would be great to create a tag and then the release notes (which will be in gitlab, as is our practice). But I do not think it's the priority right now, hence the title [DO NOT MERGE]

[ebma]

This is an interesting change for sure. I think the word 'workflow' in this comment was not necessarily referring to a Github workflow but why not 😅

The problem I see with this is that it doesn't mention the runtime in the title. For the other workflow, we implemented it such that the title needs to contain 'release:' + either 'amplitude' or 'pendulum'. This is missing in this node version bump title. Now the question is how do we want to decide whether it should be for amplitude or pendulum? If we look at our usual flow, our release cycle is Foucoco -> Amplitude -> Pendulum. So this node version bump actually needs to happen when we upgrade the runtime on Foucoco. Our automated runtime upgrade workflow does not cover this, though, as we didn't include Foucoco in that. I think we could do one of the following:

1. Add Foucoco to the release workflow and change the version-workflow to always define release: ... Foucoco in the title. Then the node version is always bumped in time.
2. Remove release: from the title of the PRs automatically created by this workflow and then we need to take care of the rest manually as per usual.

Since so far, we don't really have a well-defined process for creating and deploying the node upgrade in the first place, maybe option 1) is preferable. WDYT @pendulum-chain/devs?

[gianfra-t]

So if I understand idea 1 correctly, once we perform a change to the node and trigger this version-workflow, it will also trigger a Foucoco release. But couldn't the node and runtime upgrades be independent of each other? Because we may update the node but not make any change to the runtime itself I assume.

[ebma]

But couldn't the node and runtime upgrades be independent of each other? Because we may update the node but not make any change to the runtime itself I assume.

While this is true, I think this is rarely the case and most of the time, we'll only want to ship a node upgrade in combination with a runtime upgrade. So maybe it's better not to handle that edge case for the sake of simplicity.

[b-yap]

@ebma @gianfra-t
From what I remember, Node upgrade is independent from the runtime release, and should be performed on all runtimes. https://satoshipay.slack.com/archives/C047E2XQ160/p1710232364946679

We have never defined "foucoco release"; what's the criteria? Also, adding a specific "foucoco release" in a PR title will seem as if the node upgrade is only for foucoco.

The upcoming polkadot-v1.0.0 will change the version of the spacewalk dependency in pendulum-node, and upgrade is for all runtimes. I think a PR that states "node release" is appropriate to trigger this, right? Not necessarily Foucoco.

[gianfra-t]

I think a PR that states "node release" is appropriate to trigger this, right? Not necessarily Foucoco.

So it then would be independent of the runtime? I would prefer this. I understand the last @ebma comment as follows: we will (almost) always make a modification of the node code while also doing so on the runtime, which will generally be Foucoco.

But, once the node code has been bumped (and changed), should we also bump it's version for every other consequent runtime upgrade? I understood differently.

[ebma]

I checked other parachain teams.

Moonbeam has extra releases for just the collator nodes however. This is an example of a node release and this of the runtime.

From what I can tell, centrifuge only have the runtimes in their releases.

Astar add their collators to the assets of each release and so does interlay. We cannot apply this to us though as they group their runtime releases and do one release for all at the same time, while we have separate releases for Amplitude and Pendulum.

[b-yap]

@ebma We can definitely follow moonbeam. I'll check their workflow and update this PR next week.

[ebma]

Cool 👍

@pendulum-chain/devs any objections if in addition to our current workflow, we share upgrades to the collator nodes (and the new build artifacts) in separate releases on Github?

[TorstenStueber]

So if I understand this right with this PR we would have the following process:

• a manual git workflow to create a PR that simply bumps the Cargo.toml version of the node
• this is then independent of GitHub releases for runtime versions (for Amplitude and Pendulum separately) we create mostly manually

I think it makes sense to keep this separate conceptually as the node release applies to all runtimes at the same time – even if we will practically mostly only update the node version together with at least one runtime upgrade.

Shall we also create a GitHub release whenever we upgrade the node version or at least create a tag for the merge commit of the PR?

[ebma]

Yes, I think we should put the node upgrades into separate Github releases similar to what Moonbeam does.

[b-yap]

@ebma @TorstenStueber We'll need @zoveress to setup the release on gitlab.

I've setup the get_commit.sh, similar to the runtime-upgrade-automation. We just have to decide the assets to attach;

• pendulum-node binary
• source code of only the node? Or the entire pendulum?

[ebma]

I've setup the get_commit.sh, similar to the runtime-upgrade-automation. We just have to decide the assets to attach; pendulum-node binary source code of only the node? Or the entire pendulum?

I think it's fine if we just attach the compiled node binary to the release. The .zip file of the source code is always attached to a Github release anyway, so nothing to add here. Let's coordinate with @zoveress next week.

[ebma]

The actions added to this PR were tested here.