Release branch creation

[muharem]

Problem

The parachains' release branch creation is manual, requires a release engineer to follow the creation of the release branch for polkadot repo.
The team (CGP) do not get notified automatically when the branch is created.

Context

The parachains' release is built and published for every release of the relay chains (runtimes from polkadot repo). It requires a release engineer to follow the polkadot repository, create the release branch manually and trigger some checks.
The team might not get notified that the branch was created.
As part of the release process automation initiative (#1657) we try to improve the current process and bring more automation.

Task

• create CI job to create release branch and perform initial checks, dependancy updates, create PRs if required;
• the CI job bump the spec_version and creates a PR into the release branch;
• automatically trigger the CI job in 24 hours (TODO review the interval) after polkadot release branch is created;
• automatically notify team member about the release branch creation via message into a matrix room;
• the next automatic start of the CI job can be disabled
• the CI job can be triggered manually

[chevdor]

While the goal is to automate as much as possible, some of the steps are still manual today for the following reasons:

• scripts do not / did not exist. We are in the process of building those in here
• any solution we use need to allow for emergency releases
• some of the steps are done on local machines (luckily this is not a requirement for the runtimes)
• while we have scripts to perform most of the tasks and an increasing number of checks, we do not have handling for all the possible fault scenarii.

create CI job to create release branch and perform initial checks, dependancy updates, create PRs if required;

This is done "manually", by the release team and via the scripts here.

the CI job bump the spec_version and creates a PR into the release branch;

We avoid making an additionnal PR to prevent the RC automation workflow to trigger 2 times and generate 2 RCs. So this is done with the step above and also script-assisted for now.

automatically trigger the CI job in 24 hours (TODO review the interval) after polkadot release branch is created;

24 hours sounds rather random. The goal here is to setup hooks (see this issue). Setting up the hook is not a real issue but we need to pass context. This is where this issue is missing.

automatically notify team member about the release branch creation via message into a matrix room;

This is partly in place today for those patterns.

This PR should help with that and it has this follow up one.

the next automatic start of the CI job can be disabled

This is why polling is not an ideal option. Using hooks, we would not need to care about disabling the CI job.

the CI job can be triggered manually

Yes, this is usually a good fall back option.

[gilescope]

Ideally the sudo feature should be an option for polkadot so that we don't need to create it/release-v0.9.X-sudo branches that we have to keep up to date with the release branch. If we can't have that, I'd like the -sudo branch to be automatically created for polkadot and kept up to date with the release branch of polkadot, and when there's new commits I'd like a new sudo build of polkadot to be created - is that something we can do? - maybe this should be lodged as a separate issue as it's relating to the polkadot repo?

[gilescope]

Given that there can only be one canonical collator node, I would like ideally that the initial branch rather than being called draft-polkadot-v0.9.X, was instead called release-v0.9.X and that was used for the node. Set the version and substrate / polkadot hash and then automatically branch off that to create the release-parachain-v9X00 branch for the runtimes. (We tag releases on those branches, everyone's happy. If someone uses the release branch before it's ready, that's their look out.). If someone wants a 'source branch' then point them at the collator release branch.